Smooth is Fast
The agile conundrum
Agile programming is all about going slow. It’s about working in small increments and reassessing your work on a weekly, if not daily basis.
All the signature elements of Agile are intrinsically slow. Most notably, agile programming is done in pairs, where two programmers sit together and design and write code as a small, tightly knit team. This, of course, slows the coding process way down because everything is verbalized and because everything is given consideration. In essence, pair programming transforms what traditionally was an internal monologue into an external dialog.
The promise of agile isn’t speed but rather it’s about not building up technical debt and design debt. Programmers avoid technical debt by taking the time to refactor their code as they write it. They avoid design debt by having users, designers, or product owners review their recent work. When this happens, chances are that the work will have to be re-done. But redoing code is slow, time consuming, and to outsiders it appears to be a waste. This is a fundamental misunderstanding of the essence of software development. It simply doesn’t matter how long it takes to make code that users want, nor does it matter how quickly one can produce code that users don’t want.
It simply doesn’t matter how long it takes to make code that users want, nor does it matter how quickly one can produce code that users don’t want.
Backtracking and reworking along the way is a substantive characteristic of being agile. Agile, after all, means being quick to change. Agilistas track velocity for a single reason: to make sure they don’t try to work too fast. Agile is about slicing the salami really thin, and eating one translucent slice at a time, before slicing another, making sure it’s correct. If anyone imagines that agile has anything to do with moving fast, they’re, well, they’re an idiot. That’s just wrong.
One of the remarkable side effects of agile done right, is that lots of unnecessary features are identified early in the process. Agile is a pretty good tool for discovering what exploratory code should not be turned into production code.
The tactical sloth of agile yields significant advantages in strategic speed.
Traditional, unreflective coding methods frequently write code that never ships, no one wants, and never gets used; it’s wasted code. Without a doubt, wasted code is the single biggest drain of corporate resources. Now, I’m talking about production code here, not experimental spikes or learning adventures — that’s a very different kind of code. But wasted code that is thoroughly written, well-tested, and refactored enough to ship, is just a colossal waste of precious resources. Not only is it wasteful in itself, but it’s expensive in opportunity cost. Opportunity cost being the price of what you did not do while you were busy doing the wrong thing. Bigger corporations can more easily absorb opportunity cost, but it can be deadly for startups.
Jet fighter pilots have a saying: Slow is smooth, and smooth is fast. That is, if you try to go fast, you’ll just slam the throttle around, generate drag from overextended control surfaces, overshoot or undershoot your turns, and generally waste energy recovering from your mistakes. But remarkably, if you try to fly as smoothly as possible, applying only the gentlest pressure to the control surfaces and moving the throttle in small increments, you will speed up. Of course, you have to slow down to achieve that level of smoothness on the controls. That apparent conundrum is pretty much what agile is all about: Going slow to go smooth to go fast.
What I’m trying to say here is that the tactical sloth of agile yields significant advantages in strategic speed. If you slow down enough to be truly agile, you will get things done faster. Yes, agile is faster, but if you try to go faster with agile, you’re an idiot, and you’ll go much slower and have a crappy product and piss everybody off.
