After a while, I can guess where bad code comes from. Code that is hastily written by someone experienced is very different than code assembled by the inexperienced and without good guidance. Feature creep also has an obvious quality. Trying to turn these things into simple metrics is very much a mistake.

Absolutely. The best maintenance I do isn't renaming a bunch of properties, or putting in better exception handling. It's deciding that entire features or the basic approach to a problem is fundamentally flawed and needs to be scrapped.

You do this work long enough, and you can usually tell in under a minute if you're dealing with code that takes shortcuts, or a big pile of copypasta from SO.

Yeah but there’s money to be had from people who will buy into that idea. People don’t like complex answers.

I worked for three years at a company that prided itself on being “entrepreneurial”. In practice this meant that management could add/subtract features at will and even launch new products. There was always time pressure due to a strong annual cycle in the core business. The code was atrocious - largely because maintenance couldn’t be done properly. We never had time to refactor/re-write. When we spoke to them about technical debt and the need to address it or our productivity would approach zero as we dealt with unmaintable code and crazy bugs. Their answer? Let’s offshore maintenance. I left after that.

Software creation (is it really 'engineering'?) lives in the penumbra between arts and science. This leaves it open to interpretations and conjectures from various points of view. The definitive assessment has yet to be made.

This is where we revive the debate about whether programming can be creative because it follows such rigid syntax rules. The unenlightened say it's not, and the obsessed say it is. How do we communicate across this gap?

Programming languages having rigid syntax is like English being limited to the Latin alphabet - the opportunities for creativity lie in the combinations of higher level structures.

That's a good way to put it. The ones who think it's an uncreative field are usually the ones who struggled through learning the syntax, and therefore assumed that's what the hard part of the job is.

Thinking that an unambiguous syntax implies it's not creative means something that is creative must have an ambiguous syntax. That's on its face absurd, yet a weirdly common belief.

Can we agree that sonnets are uncreative and that heroic couplets are?

Constraints and Creativity go hand-in-hand.

Great article. I totally agree, but I see alot of Stripe developers seem to forget that 99% of software is maintained in large companies and outside of their "startup" mindset where code doesn't always live that long

It says something about the state of software development in the 21st century that I thought it was pretty brave of the author to put his actual name to that. (And FWIW, I absolutely agree).

> How many hours per week do you estimate developers at your company waste on maintenance (i.e. dealing with bad code / errors, debugging, refactoring, modifying)?

The question above is mixing dealing with errors and debugging with refactoring and modifying. I think this is the heart of the issue. One can (and should) modify and refactor "good" code too.

After the landing page I didn't even went ahead and read the report because I dismissed it as content marketing. You can see the entire thing is targeted at managers not at software engineers.