There’s a little joke that’s common to probably every software programmer on the planet.
It boils down to the idea that the only GOOD code that exists is the code a programmer writes for himself.
I’m just making an educated guess here, but I’m going to make the statement that MOST software projects which software programmers work on are NOT shiny new greenfield projects.
They’re usually software projects they’ve inherited from previous developers who may no longer be part of their team, or it could be a piece of software that was purchased from a third party vendor, but is now part of their responsibility to keep up and running.
It happens to myself more often than not. It’s actually a pretty rare situation where I find myself in the lucky position of working on a fresh new greenfield project where I get to call all the technical shots, and pick out my technical stack and programming language(s) that I want to use to code my new application.
What usually happens is I take over an existing project and maintain and add new features and functionality to it. This is often referred to as working on “brownfield” projects.
It’s definitely not the most exciting type of project to work on.
If given a choice, every software developer on the planet would rather choose a fresh greenfield project over an existing brownfield project.
But like that old saying goes, “if wishers were horses, then beggars would ride…”
One common gut reaction that probably every developer has when they have to take on an existing brownfield project is the desire to rewrite the whole thing.
In fact, one of my recent managers was fond of saying, ” … said every developer ever!”, whenever he heard one of his developer employees say they wish they could rewrite something to their liking.
It’s no secret it’s a very common opinion among many developers, including myself.
To this day, when I come across some codebase that I need to take over from a previous developer or team, sooner or later, I get befuddled and frustrated because I don’t have the temerity to instantly understand the entire codebase the first time I read it.
So I end up thinking to myself, “What kind of madman created this plate of spaghetti code? Nobody can possibly understand what’s going on! We might as well go back to the drawing board and rewrite the whole thing, and we’ll end up making it a thousand times better!”
SAID EVERY DEVELOPER EVER. My manager may have been right about this. I hate when he’s right.
I shouldn’t really be surprised by my attitude … we’re really talking about human nature here. We all have at least a little bit of ego wrapped up in our sense of self … and the workplace is no different. We all like to think that we’re good at our job. Maybe even better than other coworkers.
So when we come across work by others, it’s only natural to compare our own work against their own.
And unless there’s someone out there who’s truly selfless and altruistic, there’s going to be a natural inclination that our own work is better than the next guy’s.
It’s an uncomfortable thought, but human nature isn’t always shiny.
I’m the first to admit I’ve thought that same attitude plenty of times in the past … that it would just be better to rewrite someone else’s code, rather than spend the time and effort to figure it out and ways to help improve it.
Rewrite the code or work within its confines and figure out ways to improve it?
To be or not to be? That is the question indeed, Mr. Shakespeare!
These days, I try not to succumb so easily to my default preference, which is to trust myself to completely rewrite someone else’s codebase.
It’s taken years for me to realize this, but I finally came to the conclusion that rewriting someone else’s application doesn’t guarantee success. In fact, it can actually make things worse.
As a developer, just because I don’t like someone else’s codebase, doesn’t mean the code is necessarily bad.
It could be any number of reasons why I may feel I need to rewrite an existing codebase.
Perhaps I just don’t understand something about the code. Maybe the codebase utilizes a particular database I don’t quite understand. Or an algorithm I haven’t come across before. Or a framework I’ve never seen before.
Or any other of number of concepts, software libraries, software architecture, or any other aspect of programming.
It’s human nature that you distrust or fear something you don’t understand or have experienced before.
And your gut reaction is to go back to something that feels familiar and comfortable. And for many software programmers, the way to get back to that comfortable state is to completely rewrite an application into something more their liking.
I’m sure there’s a little bit of ego in mixed up in there as well …
I KNOW BETTER THAN ANYONE ELSE, SO I SHOULD BE THE ONE WHO SHOULD REWRITE THE APP! AND THIS TIME, I’LL DO IT RIGHT.
Said every developer ever, indeed.
The problem with completely rewriting an application is rewriting code can introduce a whole new set of problems.
The same maxim about coding remains the same, even if you decide to rewrite an application which is this:
Every new line of code is a potential new source of a bug or set of bugs.
As desirable as rewriting code from scratch is to software developers is, there’s a reason why even the biggest and most powerful technology companies on the planet don’t rewrite their software from scratch very often.
Take Microsoft and Apple.
Let’s take Microsoft first. They have two “crown jewel” software products that have made and continue to make the bulk of their financial fortunes … Microsoft Windows, their flagship operating system, and Microsoft Office, their flagship business productivity software suite.
There is no question both Windows and Office have been runaway bestsellers. Microsoft has sold hundreds of millions of copies of Windows and Office software (perhaps they’ve even reached or exceeded the one billion mark) and to this day, are both considered the “gold standard” of their respective categories, by the most powerful Fortune 500 companies on the planet.
Not to mention the millions and millions of personal consumers who use Windows and Office on their personal computer, laptops, tablets and smartphones.
As popular as Windows is, it’s an old piece of software. Version 1.0 of Windows first came out in 1985. It’s officially up to version 10.0 now…that’s about thirty two years.
In technology, 32 years is a LOT of water under the bridge.
In all that time, Windows has naturally grown in size, adding new features and functionality.
In terms of software, this equates to more and more lines of code contributing to the overall source code base.
I googled the estimated total number of lines of raw source in the latest version of Windows, and it’s somewhere north of 50 million lines of code.
FIFTY MILLION LINES.
How much you wanna bet a lot of that code was around when version 1.0 was released? I have no doubt because even in the latest Microsoft software libraries and frameworks still reference very very old versions of code, that came out twenty years ago.
You might be wondering why on earth Microsoft didn’t clean up and/or rewrite a lot of that old code?
I’m only speculating here, but from a business perspective, Microsoft was probably too busy thinking about their next version of Windows, and less about cleaning up and maintaining what they already had. They clearly wanted dominant marketshare and to do that, Microsoft needed to focus on continuing to add new features and functionality to lure new customers.
To completely stop and take the time to rewrite Windows in its current size would be madness. I doubt there’s anyone left at Microsoft who completely understands what a lot of that old code does.
Sure, the technical debt that accrued over the years in Microsoft’s Windows codebase became very large, but the top management, including Bill Gates, was willing to accept the fact that technical debt would grow over time in exchange for making Windows the dominant commercial operating system on the planet.
Before Steve Jobs returned to Apple, Apple was on a mission to replace their own aging operating system that came out with the very first Macintosh computer. Over the years, their Mac OS was getting crusty with age as well and they launched a project, code named “Copeland”, to replace their aging operating system, with something more modern and efficient.
However, Apple was never successfully able to rewrite a new OS from scratch either. It was simply too complex, too expensive and would cost too many resources, to accomplish.
They wisely decided to purchase the operating system, NeXT from the company Steve Jobs founded after he was ousted from Apple in the mid 1980s.
It turned out to be the smartest business decision Apple ever made. The NeXT operating system was a smartly built piece of software built on the rock solid foundation of UNIX and already had a large base of 3rd party software built on the NeXT operating system platform.
Apple was able to use the NeXT operating system as the foundation for Mac OS X, their official next generation operating system for their Macintosh computer platform.
In fact, Mac OS X was so successful, it eventually powered Apple’s future devices like the iPod, the iPhone, iPad, Apple TV and Apple Watch. It even powers their automative operating system, Carplay, and there is no doubt it will power brand new future Apple products and devices.
All because Apple realized that rewriting their operating system from scratch was a future and money draining waste of time and resources.
There are plenty of things you can do to improve a piece of software without having to throw the whole thing away and rewrite it from scratch.
Like IMPROVING what you already have … in technical terms, this is referred to as “refactoring the code”.
It’s not about completely rewriting the code…it’s about changing the code just enough so it functions more efficiently.
And it almost goes without saying that in order to successfully refactor code, you unit test what you’ve refactored, to ensure your refactored code works as designed.
In most cases, improving the overall quality of a piece of software can be done without rewriting from scratch.
Are there ever times where you have no choice except to COMPLETELY rewrite something from scratch?
I’ve blogged about this in the past, but sometimes I believe you can reach a certain technical “point of no return”.
Where the technical debt of a codebase becomes so great that it would just cost too much in terms of time, money and resources to try to refactor piecemeal.
There can come a point where the technical stack and/or programming language becomes so old, that there is literally no one left at a company or organization who knows how to fix it, let alone add enhancements and functionality. And finding anyone outside the company willing to work with an ancient legacy codebase will be just as futile.
So yes, I believe there are truly times where one has no choice but to completely rewrite software from scratch.
But I believe those situations are the exception and not the norm.
As a developer, I can assure you this conclusion is not an easy thing to say. I’m currently working on maintaining and enhancing an existing brownfield codebase, and there’s nothing more I’d like to do than blow it to smithereens and start with a clean slate.
Said every developer ever…
