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…
