The Point

July 19, 2012

Let’s briefly take a step back. Yes, we’re all very concerned with how best to drive software development. We love our methodologies and our philosophies — our little software calendar platitudes and acronyms. We love Martin Fowler, Kent Beck, Eric Evans, Bob Martin, so on and so forth. But really, what is the point? This article is for  everyone who has ever been subjected to my ongoing ramblings and critiques of software, processes, and team dynamics. I’d like to try to offer you a moment — if ever so brief — of catharsis. These were my intentions. Here was my point.

When you understand TDD, you realize that it’s actually extremely compelling if you want to facilitate rapid changes to a codebase while ensuring that quality is built into the product, rather than added retroactively later. When you start to understand the advantages of pair programming, you realize the distribution of domain knowledge and understanding on a daily basis is beneficial to the product. When we debate design patterns and evaluate code on the basis of the S.O.L.I.D. principles, it’s because an object having one responsibility leads to simpler designs that are easier to use to recompose into new features, rather than duplicate concepts, which reduces effort in maintaining and extending the product.

Are you seeing a trend? It’s about the product. Nothing — not good architecture, not clean code, not unit tests or test-driven development, not Agile practices, not pair programming, not domain-driven design, not adaptive software — I mean, none of it is important if it doesn’t facilitate a quality product, faster. That’s it. That was the point. All of the critiques and conversations about how to build software better is about how to implement a strong vision rapidly with acceptably high quality. So you can make money. So we can have jobs. So people can have better lives. This is, and has always been, about building the product. Anyone who cares about any of this for another reason should not be trusted, because they have some other priority than simply building a great product quickly. Neil said it best: nothing matters more than coding fast.


John is a serial conversationalist who spends entirely too much time engulfed in problem domains he knows nothing about and has no earthly business trying to learn. He can occasionally be found at your local coffee shop writing algorithms and trying to think deep thoughts.