What follows is the first chapter of an executive briefing on Tidy First? I’ve noticed that engineers practicing software design are often hindered by the incentives around them. Introducing executives, investors, & non-engineering parts of the organization to the strategic role software design can play will help make software more valuable & the work of programmers more impactful.
Future chapters will be published weekly to paying subscribers (or you can wait for O’Reilly to publish the finished product). If you don’t want to miss out, subscribe now. Paying subscribers also receive a weekly Thinkie, a habit of creative thought described by readers as “transformative”.
Welcome to the world of software development, a realm where the pace and quality of progress can tell two different stories. Imagine, if you will, two teams well into their software development journeys. Both started with energy and ambition, but as time ticks by, their paths diverge, painting contrasting pictures of success and struggle.
Vision One: The Sinking Ship
The first team started strong but as the project grew, so do its problems. It was like adding more people to a band without tuning the instruments–-the music got louder, but the sound got worse.
As the team expanded, each new programmer added less to the team’s velocity. It wasn’t just diminishing returns. Eventually new programmers seemed to reduce visible progress. The codebase became a tangled mess, more spaghetti than lasagna. Features that would have been a snap a year ago now take ages to build, Programmers swat at the cloud of bugs, distracting from progress. Manual processes & rework pile up like a stack of unpaid bills.
Good developers start feeling like they’re aboard the Titanic, and seek the lifeboats. What remains is a group of demotivated individuals, barely keeping the lights on, let alone innovating or improving. The business suffers, as it’s unable to adapt quickly to market changes or customer needs. Is this The Way?
Vision Two: The Rocket Ship
The second team not only maintained its initial momentum but accelerates over time. Here, every new programmer is like a turbo boost, propelling the project forward. The codebase is clean, well- organized, and adaptable—a well-oiled machine. Sudden changes are met with aplomb.
This team responds to business demands with agility and confidence. They’re not just meeting expectations; they’re exceeding them, delivering "happy surprises" regularly. It’s like a band where every new song is a hit, delighting fans and critics alike.
In this utopia, the team’s morale is sky-high. Talented developers flock to this group, attracted by its culture of innovation, excellence, and job satisfaction. The business thrives, quickly pivoting to seize new opportunities and effortlessly adapting to changes.
Sound like a fairy tale? I’ve lived it. I’ve helped create it. You can too.
The Executive’s Role: Creating the Difference
As an executive, you hold the power to steer your team’s ship towards the successful vision. One ingredient is cultivating a norm of continual improvement in software design. It’s about creating an environment where refactoring isn’t an afterthought but a core practice, where quality is non- negotiable, and where learning and growth are part of the daily routine.
Encourage your teams to view the codebase as a garden that needs regular tending, not a bare field on which you scatter seeds before walking away. Invest in tools and practices that promote tidy code, automated testing, and efficient workflows. Foster a culture of open communication, collaboration, and constructive feedback. Remember, a team that learns and improves together, accelerates together.
Maybe you’ve never been a programmer, or maybe your programming days are in the rear view mirror, but understanding just enough about software design to encourage its effective application is a learnable skill. With the fundamentals of software design in hand, you’ll be able to diagnose ineffective teams, speak knowledgeably to both business & technology folks, & encourage the creation of the Surprise Factory.
Outline
Chapter 2: 3X Explore/Expand/Extract—why what got us here in software development won’t get us there.
Chapter 3: Economic Drivers of Software Development—money shapes design. Net present value suggests earning sooner & spending later, but your software is also a portfolio of options that requires your attention.
Chapter 4: Features & Design, A Dance of Contrasts—healthy software products & organizations need both.
Chapter 5: Coupling, or Why Software Costs So Damn Much. Like an avalanche, some "simple" features trigger a cascade of changes.
Chapter 6: Cohesion, or Reducing Costs When You Can’t Eliminate Them. Even when change spreads, you can manage the damage.
Chapter 7: Incentives—what you can do about underinvestment in design. Your teams are acting rationally in an irrational system. You can change that system.
Chapter 8: The Tech Executive’s Software Design Toolkit—what to do next & what not to do.
Conclusion: Leading the Charge in Software
Innovation
The book calls you, a technology executive, to action. Embrace the role of a visionary leader who understands enough of software development to speak knowledgeably to everyone involved & inspires teams to greatness. The journey doesn’t end with this book; this book is a gate to a path of learning, adapting, and leading in the ever-evolving realm of software development.
Up Next: The 3X Factor - Explore, Expand, Extract
In our next chapter, we dive into the 3X model: Explore, Expand, Extract. This powerful framework can be your roadmap to achieving high-speed, high-quality software development. It’s about understanding the lifecycle of successful software initiatives and strategically navigating each phase. Stay tuned for an insightful journey through the stages of exploration, expansion, and extraction, where you’ll learn how to maximize value at each step. Get ready to transform the way you think about software development!
> It’s about creating an environment where refactoring isn’t an afterthought but a core practice, where quality is non- negotiable, and where learning and growth are part of the daily routine.
The difficulty here is that quality is always negotiable. That’s one of the core lessons in _Tidy First?_: it's always a choice, and sometimes the correct choice defers making an improvement until later.
- - -
Part of the background behind _Tidy First?_ is, I believe, a reaction against refactoring and TDD. I think I missed that. I know Coplien’s fine essay about “Most Testing Is Waste”; I don’t agree, but its argument is certainly something to take into account. But this cannot be what you are reacting to; it seems no longer to be available anywhere. What is the best counter-manifesto?
If I may also add, money shapes the Team. Kindly share your industry experience with global team and any trending management of it. I ask that so I don’t go ranting about my pains :) instead I like to learn more. Thanks