Doc's Blog — Doc Norton & Associates

Software Excellence

Measuring Agile Efficiency

Measuring Agile Efficiency

This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”

To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).

Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.

That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.

Removing Code Duplication

Today’s offering is another post inspired by a question on Quora about when to refactor away duplicate code.

The specific question was, “What is the limit for duplicate code to start refactoring?”

I took this to mean, “How much duplication needs to exist before you should refactor it?”

And I’m not sure that’s really a great question. So I decided to start with clarifying what duplication needs to be cleaned up and then when might that happen.

When to Refactor Your Code

For me, refactoring is when we change the implementation of a piece of code without changing the behavior. That’s the entire definition - Change the implementation, but not the behavior.

As a result, I will generally not refactor code unless it has a solid set of tests around it. If I see code that needs refactoring, but has insufficient tests, I will add character tests.

Refactor - You Keep Using That Word…

I stumbled upon a thread recently where the question was posed, “What are some common mistakes when refactoring code?”

The answers were interesting. The more I read, the more I realized that folks weren’t talking about the same thing. They were all saying “refactor”, but many were describing scenarios that sounded more like a rewrite rather than a refactor. This is not uncommon. I’ve encountered this on multiple forums, in slack discussions, in blog posts, and in actual human to human conversation (it happens).

Remediating Technical Debt

I no longer believe we can return to the original, healthy and helpful definition of Technical Debt. Nor do I think we’re going to shift away from it to a better metaphor.

But maybe we can talk about remediation of Technical Debt in a way that helps us make better decisions.

The way I see it, Technical Debt Remediation is nothing more than Maintenance. Maintenance is to keep in an existing state (as of repair, efficiency, or validity) or to preserve from failure or decline.

Technical Debt Remediation (Maintenance) comes in different categories – Preventative, Deferred, and Repair.

Thoughts on Refactoring

Thoughts on Refactoring

I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.

Technical Debt and Accountability

Technical Debt and Accountability

I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say. 

Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.

Code Profiling

Code Profiling

I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:

Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.

Good Software

I saw a tweet this morning that caught me off-guard.

If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile — AgileFortune (@AgileFortune) July 23, 2015

It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.