“Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’” – Marty Cagan in his book, Inspired: How To Create Products Customers Love.
Hitting this wall is definitely a BAD thing. And it sneaks up on you. Bob Martin discusses this in his book, Clean Code: “Teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Have you ever waded through a mess so grave that it took weeks to do what should have taken hours?“
Where does the fault lie? Marty Cagan and Bob Martin offer two different opinions:
“…the harsh truth is that it’s usually the fault of product management. The reason is that when this comes up, it’s usually because for several years, product managers have been pounding the engineering organization to deliver as many features as the engineering team possibly can produce.” – Marty Cagan
“The fault is ours. (Developers) Not the requirements, not the schedule, not the stupid managers and useless marketing types.” – Bob Martin
To me, this reflects a certain healthy tension that should exist. The business wants a certain feature set, and it needs to rigorously define and prioritize what they want, understanding that certain things won’t be possible. (At least not within certain time frames.) The development organization has a professional responsibility to deliver those features with high quality and well-designed, so that the software can be added to and maintained as an asset, not a liability.
There needs to be a candid conversation about expectations. If you are building something that is a one-off prototype, that’s one thing. If the intent is to build something that will serve as a foundation for continued development and exploitation by the business, that’s a different ball game altogether.
This means that developers shouldn’t call a feature “done” once it works. I’ll refer back to Bob Martin on this one. “Getting software to work and making software clean are two very different activities. The problem is that too many of us think that we are done once the program works.“
It’s like writing; the first draft is usually a little messier than the final article. More often than not, I strip things out of my first draft versus adding any actual content. I concentrate on taking out extraneous sentences and re-wording others to bring greater clarity to what I’m discussing. (Some of you may think that I’m still a little long-winded and less than clear. And that’s true. Call me on it!)
A good, sustainable pace is what you want out of your teams. And that pace may not provide the feature throughput that you would like by the time development teams factor in everything that goes into producing high-quality, well-designed code complete with automated tests. Ask questions of teams that start out fast to make sure that they're not building a mess. Make it clear that you want to avoid getting into that house-of-cards problem later because it will shorten the life of a product and reduce your overall return on investment.