[fifticon]

I have my own theory on this. Green-field projects are usually whipped up and rolled out by the experienced devs in the shop. Once the boat is in the water and floating, the senior devs are posted off to next new-dev initiative, and the following maintenance/deployment work is assigned to less and less senior devs, and/or student programmers. Within 2-3 years, those inexperienced devs have mangled the original design into unrecognisability, and the application accumulates instabilities from their bolted-on "fixes". A different perspective is that the original creators are never allowed back to fix their design mistakes. I don't know if it's universal, but I have sure seen it in a lot of places, and I have myself been in most of those roles hinted at.

[SketchySeaBeast]

Disclaimer - my job is literally to take on the long term maintenance of those green field projects.

I wouldn't necessarily blame it on a lack of seniority or inexperience, it's a matter of not knowing the initial style, decisions, and limitations, as well as the vagaries of time. I find myself creating duplicate functions not because I wouldn't reuse the ones that exist, but because the original one was hidden away in a different place than I'd ever think to look for them. My approach is different and drifts even further over the years, I can't help it, so that the project starts to look stranger and stranger comparing the old code to the new. The original designers would find their style drifting too if they had to take care of a system for that long. They are just lucky enough that their style drift has project cut-offs, so each slice seems more cohesive.

I also don't know if this is a current maxim or not, but there should be a software principle that matches Peter's - every successful system will grow until it reaches a point where it's no longer successful. More and more requirements get added on, and unlike initial requirements where you could justify keeping scope tight due to staying lean, a system needs to grow beyond it's current limitations or it dies.

[kabes]

It's also that requirements often change in ways the original design hadn't foreseen. And usually there's no time for a decent redesign, so things get hacked together and slowly degrade hack by hack

[JohnBooty]

This matches pretty closely with my experience.

An additional side effect is that management fails to understand what/why is going on and overvalues the skills of the "experienced devs" and undervalues the skills of the maintenance devs because they don't understand the order-of-magnitude speed advantage enjoyed by devs when writing greenfield code.

"Experienced Developer A wrote the whole damn system in three months! Now Maintenance Developer B wants three months just to add a few buttons?!?"

I've been both the experienced person and the junior maintenance person.

[nuancebydefault]

Exactly! As a maintenance dev, you tend not to get much praise, you need to continuously explain why things take so long. I'm currently adapting some code that is, in the eyes of management, adding an extra little wire, which should not be more than a day of work. In effect it will be more than 4 days plus some overtime...

[JohnBooty]

Yeah. I've been in the industry for 20+ years and I have not figured out a way to "shine" when tasked with maintenance work, other than finding ways to avoid such roles entirely.

The root issue is that management never seems to be able to grasp things on a technical level. I've tried to communicate this over the years, and have been praised for my communication skills in general, but I've never managed to bridge this particular gap.

[disease]

This plays some part. Another factor is the old 'it is harder to read code than it is to write it' adage.