I’ve worked on some big piles of mud over the years. You know, those sprawling applications made up of millions of lines of code, written by countless developers over the course of a decade or two, most of them long forgotten and utterly unknown to the current team. The application is the foundation of a business — the flagship application! — and has code you’d be ashamed to show anyone outside of the organization. Many of you are working on such an application today.
Where do these applications come from? Well, they come from a lot of different places and they’re created in a lot of different ways. Whatever the scenario, all of these tangled messes of inscrutable code have a few common traits.
Someone’s nephew
This happens more than we care to admit. Uncle Harvey’s go-kart track needed an application to manage the racing and count the money. His nephew Todd was “good with computers” and cobbled together some Visual Basic code to get things running. Uncle Harvey’s friend from the National Go-Kart Convention heard about it, and Todd, being an ambitious young nephew, was off to the races, building a business on the application he built with no thought to architecture or design. Years go by, and Todd has a haphazard pile of six million lines of code that only he can understand.
Bobcat code
I worked on an application where one of the founders wrote a lot of the original code and continued to add features he wanted for many years. He had this habit of writing what he called “Bobcat code,” as in “push around a bunch of code like dirt with a Bobcat to see what I could get working.” And of course, given that he was a venerated founder, no one ever had the courage to just dump his code and rewrite the feature properly.
Short-term deadlines trump good design
Because coding and feature deadlines were hard and tight, the team developed a culture of “build it fast and fix it later,” only later never comes. I still shake my head at the hacking scene in “The Social Network” where the definition of “success” was how fast developers could code while taking shots every few minutes. Has coding fast ever resulted in anything but a maintenance nightmare? No, it has not.
Management-driven timelines
And by “management” I mean “people who don’t have a clue what good software looks like and who don’t have to live with the decision to rush it.” “Deliver that feature by the end of the quarter or you are fired” isn’t conducive to elegant, maintainable solutions.
Poor early decisions
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.
Anyone can code!
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…
It’s inevitable
One way or another, it seems inevitable that any application that has been around for 30 years will, at some point, become a large frustration to a new developer on the team. It just kind of happens. I know that everyone means well, and that we have learned a lot about software development over the decades, so maybe we shouldn’t be too upset when it happens. The way we build things today and the cool frameworks we now have will almost certainly look primitive and sloppy to developers a few decades from now. It’s kind of humbling to think that the beautifully designed and meticulously coded application you’ve built will eventually decay and become a Giant Ball of Mud.