That shiny new developer job is going to involve a lot of rusty old code

Software development may seem glamorous, but the majority of any developer's time is necessarily spent maintaining old code. Get used to it.

Video: Here's the programming languages in demand, what cities they're needed, and who wants them

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).

Image: iStockphoto/g-stockstudio

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.

Also see