Why Software Design Matters
You Get Better at Design. What Happens Next?
I once talked to a technically-oriented CEO who said that when they started they were determined to only write good code. By the time they were wildly successful, their code was the same ball of mud as everybody else. “Maybe the 2 states of a system are ‘disaster’ & ‘almost disaster’.”
I know that self-reflection is out of fashion at the moment, but I gotta start by saying that maybe I’m wrong about all this. Maybe, in the larger scheme of things, software design doesn’t really matter, or only matters in rare instances. Maybe doing a better job of designing software makes no more money (or even less money).
We certainly seem to have plentiful evidence of teams seeming to invest:
Too little, too late, or
Too much, too soon
by the standards of Empirical Software Design and still supporting viable businesses.
Nevertheless
I’m going to continue to act like good design matters, because:
It feels good to improve a design.
A good design serves our teammates (& our future selves).
At the margin, a good design makes features viable that would have otherwise been uneconomic, enabling us to better serve our customers.
For Example
Here are some specific moments when I think that software design matters:
Testability. A better-designed interface is easier to test against. A better-designed implementation makes it easier to decouple tests from the structure of the code.
Confidence. Lower coupling & higher cohesion give you greater confidence that you have made behavior changes successfully.
Teamwork. Improving design, done well (the subject of book 2), makes teammates’ jobs easier.
Pride. Programming is a job both of emotional energy & intellectual insight. Improving a design feels satisfying. You see how things could be better. You make it so. Ahhhhh…
Conclusion
I’m spending some of my remaining seconds on the planet talking about software design because it is a puzzle. What are the basic forces? How can we resolve them? How do those forces interact with our human strengths & weaknesses.
I study software design because it is indeed a puzzle, a highly-technical exercise in human relationships. We’ll see if that really matters in the long run.
Software design is like salt in a recipe: too much and everyone hates it, too little and everybody asks for more. With just the right amount you get no credit and nobody thinks it added anything!
Kent Beck
I feel you. I've also been flying this banner for the last ~20 years in my own work and have proceeded with the same rationale as you, despite working with many many others who don't have the same resolve.
I have, however proven (to myself at least) as a technical founder of my own tech startup, (on the tools) that the big ball can absolutely be avoided - even after 8 years in market.
But I can only provide evidence of this at the small end of the scale of team sizes. Teams of less than 8-10.
The real challenge I see, based on lived experience across a very diverse career, working with literally 100s of codebases and teams, is that there simply is not enough evidence available to past or future developers/engineers of this working well enough - so that they just adopt it as a mater of course (lack of availability bias). and thus, we have not reached critical mass yet across the industry.
Every single one of them (after a certain stage of competence) gets it intellectually (and knows they should be doing it), but applying the necessary rigor and discipline is where most just fall back to what is easier for them. (We have a long history of geeks avoiding taking risks and responsibility, and delegating that to their bosses)
It has a lot to do with age and stage, and massively to do with the context they are in (most are just incentivized to care about problem-solving rather than the outcome they create, and too many are working in project contexts where they are not responsible for the future mess they create).
I write a lot about these contextual differences, that few programmers seem to recognize, let alone appreciate. https://jezz-santos.medium.com
Each and every developer/engineer that I have demonstrated this discipline to firsthand has been a long drawn-out campaign of its own, person by person. I have a high success rate of doing that at the individual level, but I can only affect so many.
There are just too many commoditized developers in the world today, and not enough teaching them hands-on what good looks like.