Dear Fellow Developer,
A little over twenty years ago, a group of guys went to a ski resort not far from my house and wrote the agile manifesto. Not long after, the entire industry transformed. We went from using the waterfall method of design to agile methodologies. Along with this transformation, eXtreme Programming (XP) gained traction as a new way to develop code. XP relied on a few tenets, two of which I will discuss here:
- Pair programming
- Emergent design
Back then, it was an exciting time to be a software developer. We'd been suffering with the weaknesses in the waterfall methodology and knew there had to be a better way. My team dove right into XP to give it a try. We wanted the perfect code promised in all of the XP evangelical articles. We paired up and tried to live the dream. The business, however, felt like we'd chopped their development team in half. What did we mean we needed two programmers on every assignment? That practice lasted about a month before we were told to stop.
As a matter of fact, businesses around the world didn't like pair programming, but developers recognized the value of tight feedback loops provided by pair programming. Thus was born the code review.
While few (if any) still practice XP, its legacy continues today in other ways. In addition to the code review, we were also given emergent design, a concept which sounded good on paper but resulted in decades of bad code.
For emergent design, the theory was this: you developed one requirement, wrote tests around it and moved on to the next requirement. When faced with modifying code, you were supposed to refactor ruthlessly, using unit tests to maintain the original requirement. This was supposed to cause the ideal design to emerge from the development, hence the name.
Unfortunately, no great designs emerged. In fact the opposite happened. Let's talk about how and why it failed so spectacularly.
First, there is a point in development at which it becomes no longer practical to refactor. When this point is reached, developers may choose to do a number of different things. Some patch the old code. Some copy and paste to provide a new pathway through the code. Almost all hack together a solution to the existing problem. Those hacks then become a pattern for future developers.
Another reason emergent design failed is design principles stopped being taught in dev shops. Junior programmers stopped getting the education they needed to use the emergent design methodology effectively. If someone doesn't know what good design looks like, they cannot refactor bad code into good. Instead, junior devs mimicked the bad choices of their seniors. After a couple of generations of juniors becoming seniors, the industry produced a bevy of "senior" developers who couldn't design their way out of a paper bag.
The code left behind from this disastrous era is a spaghetti bowl of bad choices and brittle classes. No one wants to work on the ugly legacy behemoth. Instead, they want to write green field applications, and unfortunately, many of them repeat the same mistakes they made in the legacy code base, because they continue to use emergent design.
While I recognize the inherent problems with waterfall's big up-front design, the industry over-corrected with emergent design and ended up in a place with little to no design at all. At some point, we must put an end to this madness.
Martin Fowler, one of the original architects of XP, wrote a keynote speech in the year 2000 called "Is Design Dead?" In it, he talked about evolutionary (emergent) and planned design. He compared the concepts behind emergent design to architecture, saying if you want to build a dog house, emergent design might work if you have a bunch of lumber, a rough idea in your head and a willingness to rebuild it if things go wrong, but what about if you're building a skyscraper? We all know a one-bedroom house wouldn't be up to code if it wasn't designed properly, but somehow we think our monoliths are going to be vast creatures housing our brilliance without doing any up-front work. We are wrong.
I have now worked in enough monoliths to speak unequivocally: emergent design is our industry's enemy #1. Even if people practiced emergent design the way it was intended (which they don't), it's not capable of working effectively within a large application, or even within a large class for that matter. It is not a forward-thinking methodology, and no brilliant design "emerges" from its use. What emerges is hacked-together spaghetti that degrades in quality the older it gets.
So how do we address these problems? The method I've found to be the most effective is using Domain Driven Design (DDD). DDD was introduced by Eric Evans in 2003 but didn't gain popularity in the industry until the era of microservices. DDD models software after business processes. Isolation of individual domains allows modularization, which lends itself well to a microservice architecture. While Vaughn Vernon has written multiple books about Domain Driven Design, the condensed version I find the most understandable is InfoQ's Domain Driven Design Quickly.
Whatever process you choose, be it DDD or another, I beg of you to abandon the practice of emergent design. Chances are you're doing it wrong, but even if you are doing it right, it's not a methodology that produces long-term quality results. Even the original architects of the methodology knew that to be true two decades ago, but human nature beckons us to take the path of least resistance, and so we've ignored the warning signs.
If you're reading this, please reconsider your use of emergent design. While we've lost the art of design in our decades of willful ignorance, we can resurrect good design practices. We can create frameworks rather than if-than-else nightmares. I believe in the brilliance of developers, which is why I'm writing this article. I beg of you to spend some time focusing on design and creating software of which you can be proud. We can and should do better, and we owe it to our future selves to try.
Happy coding!
Top comments (0)