Driving Development Without A Governor

In agile development, you hear a lot words like “lean”, “velocity”,” extreme”, and well… “agile”. They evoke an image of speed – nimble and fast, like a cat. With agile we’re supposed to be moving quickly and responding to change easily. These are both good things for sure, but is there such a thing as moving too quickly?

Speed limiters in automobiles are termed governors. One use of the governor is to limit the rotational speed of the engine to protect the engine from damage due to excessive speed. So is there such a thing in Agile development? Do we need such a thing? Agile development’s major benefit is to get continuous feedback from your customers as you build. You are continuously planning, testing, integrating, and refining as the requirements change and grow. The faster you build and deploy, the sooner you’ll get new feedback, but the rush to completion can cause its own problems.

The same way that the governor in a car prevents you from wrecking your engine, and limits how fast you could recklessly drive, an agile governor should help prevent making major errors in your code and accruing technical debt.

Technical debt can occur in several forms: pieces that were meant to be refactored never are, not enough brain cycles are put into the initial design, code gets copied and pasted more than it should. Then, when the customer gives you an approval of a feature, there is always the temptation to close the feature and move on to the next without having one last look to fix things you promised yourself you would at the end. You may end up with a feature that on the surface appears to work, but internally is hard to test, hard to read, inefficient and impossible to enhance without the fear of introducing bugs.

So we still want to deploy features fast to get feedback, but without hurting the integrity of the feature. What is the governor in agile development?

As you develop you should be writing unit tests. (You are writing unit tests, right?) This is one kind of governor.  The benefits of unit tests are well known, but it’s more than  testing correctness and finding regressions. It’s when you stop and think about the use cases and how they will be handled. In essence, it forces you to think through the problems you will encounter and design solutions to those problems. It forces you to slow down and think a little instead of just head-down code.


For a long time, we thought unit testing was enough. In the past 10 years, testing has really become mainstream, so it should be assumed at this point, right? But is there more?

We’re a small team, with a lot to do. Revolutionizing lending takes a lot of work. This isn’t a project management tool or the next wannabe social network. We can be as agile as possible, but our minimum viable product is still not very minimal. We feel the constant pressure to get the next feature checked off before we can hit our 1.0.

We have really good quality code and we were testing, but a few months ago, we put our need for speed aside, and wanted to make sure our quality was even better. We devoted even more time to our deployment process and quality assurance.   What we found is that we could improve even more. The unit tests and  testing were not enough.  A more robust quality assurance process was a speed limiter for us, but again, that might just be a good thing.

With the increased QA, we found that it would probably be worthwhile to do more code reviews. Not just sometimes. Not just when someone asks. Always. We held off on this one longest, worried about the cost in terms of productivity. What we found is that code reviews are just as important as unit testing and even more important in many respects.  Code reviews create accountability for the feature. There is something about knowing someone else will be looking at your code that encourages you to design and implement a feature well. This is the time where someone with prejudice attempts to find all flaws in the design or implementation. So it behooves the requester to look at things one more time before the code reviewer starts. It is not meant to embarrass, but an opportunity to catch issues upfront, exchange ideas, and learn the feature. It also gives the developer and reviewer an opportunity to learn from each others strengths and weaknesses. The code reviewers must not rush and just skim the code, as this bypasses all the benefits of the code review.

It is tempting to develop without tests, code review, and thorough QA, the same way some gear heads love to get rid of their speed limiters to see if they can make a car go faster than it was ever meant to. What we found, though, is that its better to get there in one piece. We can continue writing code in a fast pace but as long as we don’t rush unit testing, code reviews, and quality assurance, we’ve created an agile development environment that limits how much we can rush, which keeps us at a safe speed.

What about you? Do you drive development without a governor?