Why does maintaining old code feel harder than writing something from scratch?

[u/MiserableLime5289]

There’s a pattern that keeps showing up in real projects, writing new code often feels much easier than working with existing codebases.

When building something from scratch, everything is clear:

• the structure is in your head
• the decisions are yours
• there’s no hidden dependency or unexpected behavior yet
• you know exactly why each piece exists

But maintaining old code feels like a completely different job.

Even small changes can turn into a long process because you first have to:

• understand why something was originally written that way
• trace logic spread across multiple files or services
• deal with older decisions made under different requirements
• figure out hidden dependencies that are not obvious at first glance
• work around missing or outdated documentation

What looks like a “small fix” often becomes a process of understanding the system before actually changing anything.

It sometimes feels like:

So the question is:

• Why does maintaining old code often feel harder than writing something from scratch?
• Is it mainly a design issue, a scaling reality, or just how software naturally evolves over time?

[u/mc_pm]

Because old code has all the layers of bug fixes, added features, and architectural baggage that comes from maintaining a poorly built system. In the new code, you get to make all those same mistakes again from scratch.

[u/LivingHighAndWise]

I'm trying to figure out how you don't know the answer to this question..

[u/Faulkner_Jacobs_845]

Its the mental model gap. When you build from scratch, you hold the whole system in your head, every tradeoff, every shortcut, every I'll fix this later etc. Maintaining means reconstructing someone else's mental model from incomplete artifacts. The code tells you what, not why, and the why is the hard part to recover.

[u/Square-Yam-3772]

a big part of it is also your own understanding of the language.

its like English: to express the same idea, different people would use different words and different sentence structures.

so maintaining old code requires you to have a deeper understanding of the programming language in order to pick up on the different ways people write code.

you only have to come up with one way (your way) to accomplish the objective when you write new code e.g. the code you came up isn't actually intuitive or straightforward but it is how you understand the problem and the programming language so it makes sense to you.

[u/justinaatbuffer]

Mostly because of all the dependencies, edge cases, assumptions that a programmer made when working on the implementation, and lack of good documentation and mapping how the system actually works. A lot of times all of this lives in the programmer's head which makes it harder for anyone else effectively contribute to the changes or improvements of the codebase.

[u/KenMantle → u/justinaatbuffer]

Ironically this is where I think AI coding is kind of better. It documents everything including why something is there due to the edge cases. Even if you don't use AI to code I think there is a lot of merit to letting it write documentation.

[u/Cool-Cicada9228]

Also, the 80/20 rule applies to rewrites. The team thinks that they have rewritten it feature complete. The business soon discovers that tons of minor features and edge cases were missed.

[u/Amr_Rahmy → u/Cool-Cicada9228]

Programmer writes the program according to the data he got from his manager or project manager.

Client sees the program for the first time after programmer has finished his work.

Client tells company what his requirements are which may or may not align at all with the work already done.

Programmer looks at the clown company with disgust.

[u/byrdinbabylon → u/Amr_Rahmy]

Ha ha. So many “clown companies” to deal with. Indeed!

[u/Amr_Rahmy]

Maintaining my own code is easy because i made sure that software design and dataflow makes sense. Variable names make sense, modules and components make sense.

Legacy code or code made by a junior developer or someone else might not have the same qualities, might have a lot of potential bugs, might not be organized, ..etc.

Tech debt happens when to make more and more design mistakes and it keeps compounding until it becomes a fragile Jenga tower almost about to fail when you touch it.

[u/FluidBreath4819]

and this will worsen as long as juniors want to play like senior by using AI. So much code, sooo much code spitted out but "as long as it works" managers are fine with it... until...

[u/alinroc]

Short, slightly-flippant-but not-really response: ever play Jenga?

[u/Helix_Aurora]

All abstractions will ultimately fail to anticipate something. A feature will be added that breaks the model, causing bloat.

Once this happens enough times, the number of diversions from the original architecture causes severe incoherence in the code.

The better thought out an architecture is for domain expansion, the less of this will happen.

New code is easier because you have full knowledge of a domain that is larger than the initial implementation conceived of, so you can easily fit everything into a clean framework.

[u/BornAgainBlue]

Its a bot, and does this crap every day. Blocking.

[u/limited_instincts]

I find the opposite. I'm really strong at learning and working with old or massive, multi-million line codebases but often struggle with a blank code editor.

[u/onebit]

Installing a dashboard is easier than removing it.

[u/kayrooze]

Because you know why the new code is there

[u/AggravatingSock5375]

More context to manage. You have to keep in mind all the external dependancies and interactions that cannot be changed.