Where big piles of mud come from

Any good civil engineer will tell you that a building is only as good as its foundation, but this software was built on a foundation of jello, sand, and duct tape. Decisions were made early on that forced development to follow a certain path leading away from good and sound architecture and development practices. The realization that good architecture and coding practices are critical has led to a rise in the notion of “high-optionality software development” — the idea that development teams should from the very beginning work to keep the option of change open and avoid painting themselves into a corner.

One “hero” developer 

Sometime back in the recesses of the past, a hero arose to knock out a critical feature just in the nick of time. She was lauded as a savior, rescuing a customer demo that ended in a big sales deal. Only this developer built the feature “her way,” in some inscrutable fashion, using coding techniques only she could comprehend. And now our hero has left the company, no one can understand quite what she did, and the customer that her critical feature landed switched to a competitor a while back. 

There was a time in our industry when it was thought that, if we could just build powerful enough tools, anyone with domain knowledge could become a developer. (This notion lives on in the “no code” craze.) Maybe your company bought into the RAD (rapid application development) and CASE (computer-aided software engineering) tool craze of the 1990s and asked the development team to build a client-server prototype of a new accounting application. The team started dropping buttons and filling out onClick handlers and never looked back. Things worked right out of the gate because the gizmo let you build a working prototype quickly—and why would you stop to rewrite the thing when it works just fine right now? I think we all cringe at the words, “Why don’t we just ship the prototype?” And yet…