Developers may dream of dancing lightly through the pristine pastures of greenfield development, but reality is quite different, and looks a lot like a cow pie. Referencing a classic Svante Lindqvist essay, professor David Edgerton pointed out that "roughly 70% of engineers work on maintenance/operations, not design."
The ever colorful Honeycomb founder Charity Majors stated it a bit more bluntly: "[Y]our greenfield coding skills are about as useful as your Renaissance Art degree." In other words, while developers dream of building the next great AI-driven application, they're probably going to spend more time connecting it into a morass of crufty legacy code.
Who to blame for those 'favelas in code?'
At some point, every enterprise got to indulge in greenfield software development, defined by many as a project "lack[ing] any constraints imposed by prior work." That newly-funded startup gets to indulge in lots of greenfield development; the Fortune 500 enterprise, however, is shackled to years of preexisting code.
Over time, this code builds up and creates all sorts of problems, as Princeton CITP fellow Zeynep Tufekci described:
Think of it as needing more space in your house, so you decide you want to build a second story. But the house was never built right to begin with, with no proper architectural planning, and you don't really know which are the weight-bearing walls. You make your best guess, go up a floor and ... cross your fingers. And then you do it again. That is how a lot of our older software systems that control crucial parts of infrastructure are run. This works for a while, but every new layer adds more vulnerability. We are building skyscraper favelas in code—in earthquake zones.
SEE: Developers are pragmatic, not religious, about software (TechRepublic)
As comforting as it may be to blame the idiots who came before us at a particular employer, the reality of software development is that there are all sorts of good reasons for bad code. In a blog post, Majors broke it down as a management issue:
Being an individual contributor is like reverse-engineering how a company works with very little information. A lot of things seem ridiculous, or pointless or inefficient from the perspective of a leaf node. Being a manager teaches you how the business works.
This management perspective, in other words, introduces a developer to why the code has become such a spaghetti'd mess.
Maintaining what works is your job
Steven Lowe's tongue-in-cheek comment that "[I]t's legacy code if you didn't write it" rings true. I don't meet many developers who don't think their code is better than code they inherit. Heck, they might even be right, because often developers compare what they'd write in a greenfield scenario to what another developer was forced to write under duress (i.e., making it compatible with older systems that fit that "favelas in code" comment above).
Regardless, most developers are going to spend most of their time maintaining code, not writing greenfield code. That's just how it is, particularly for the bulk of jobs where a developer must build on previous code. For developers aching to break free of code maintenance shackles and refactor that code, this advice on a Software Engineering Stack Exchange thread seems warranted: "[Y]ou have to realize that to a company, having code that works is more important than having code that is clean. From your company's perspective, you changing the existing structure is money wasted on redoing something that is already done and potentially introducing even more errors."
SEE: COBOL programmers know old != bad (TechRepublic)
Of course, a major overhaul of software is sometimes warranted. At MongoDB, Adobe, and other places I've worked, such "do-overs" to eradicate technical debt have been critical ways to ensure greater flexibility in a product's codebase.
But, again, a lot of software development, most of the time, is all about maintaining code by fixing bugs and such, rather than greenfield development. Yes, that may mean adding another layer to that "favela," but that's why software developers get paid so much.
- Why every developer is an open source developer now (TechRepublic)
- COBOL programmers know old != bad (TechRepublic)
- Developers are pragmatic, not religious, about software (TechRepublic)
- Why AWS Lambda could be the worst thing to happen to open source (TechRepublic)
- Why the notion that everyone should learn to code is complete rubbish (TechRepublic)
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.