Just had to turn off comments since this post has become a spam target. Sorry.Update: Kent since tweeted this nice one-liner:
a complete engineer can code for latency or throughput and knows when and how to switch
Kent Beck’s excellent keynote at the Startup Lessons Learned Conference has been attracting some attention on The Interweb. In particular, it seems like he’s now saying that careful engineering is wasteful—just copy and tweak those files to get a result now. I can already hear how this will be cited by frustrated proprietors and managers around the world (more on this in a moment).
What I think he actually said is that we should make engineering trade-offs. When we’re concerned with learning, then we want the fastest turnaround possible. It’s like a physics apparatus, it’s over-engineered if it lasts beyond the experiment. But, if we’re delivering stuff that people will actually use, that we want them to rely on, then the trade-off is different and we should do all that testing, refactoring, and so on that he’s been talking about for the last ten years. Kent brushes over that engineering stuff in his talk, but it’s easy to forget how rare timely, quality delivery is in the field.
My favourite part is Kent’s answer to the last question. A stressed manager or owner asks how to get his developers to stop being so careful and just ship something. Kent’s reply is to present the developers with the real problem, not the manager’s solution, and let them find a way. What the manager really wants is cheap feedback on some different options. The developers, given a chance, might find a better solution altogether, without being forced into arbitrarily dropping quality.
Good developers insist on maintaining quality, partly to maintain pride in their work (as Deming proposed), but also because we’ve all learned that it’s the best route to sustained delivery.
As Brian Marick pointed out recently, it’s about achieving more (much more) through relationships, not one side or another achieving dominance.