And the only better experience than that is killing a new greenfield project before it gets to production because the old software was good enough and the problems were organizational in how the software was being used.

The best code is the code that doesn't exist.

Certainly the most secure code. Not sure about best.

Better on every axis: security, performance, resource consumption, reliability, verification, documentation...

exactly..which is also why lines of code written is one of if not the worst possible metric of productivity. easy to game too.

I marked my transition to senior engineer when my net lines of code flipped to negative.

Not that I game that obviously, it just occurred naturally for a ~4 month period

> Better on every axis...

How 'bout job security?

Anyone can write no code.

But it takes a master to not write the write piece.

I thought it was pretty funny how we had this large project that was supposed to replace a legacy system (that was mostly a bad hack that got pushed to production).

But when it was finished it failed to meet the basic requirements for the only customer that used the system.

Once you're senior enough those cases won't be funny any more, just sad.

I have a very dark sense of humor sometimes.

But yes, it's sad.

I wish this happened tbh. I've seen one where the greenfield (Scala, AWS, etc) is still living alongside the old good enough software they went back to (C# / .NET) ten years on.

Second System Syndrome! :)

https://en.m.wikipedia.org/wiki/Second-system_effect

I keep telling people v1 of anything always sucks.

One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.

> how much they disparage the previous team's work.

And many fail to discern between "disparage" and "critique" or even "Question in order to learn"

One of the greatest failings I've seen in leadership in our time is the idea that in order to make a critique one must come with a solution in hand. As a leader I want to know the things that are going wrong as soon as they're seen, not to require someone to go through the heavy lifting of a solution before they say a word. Now, of course, there's a difference between bitter unhelpful cynicism, and simply identifying a gap between the current state and optimality.

> And many fail to discern between "disparage" and "critique" or even "Question in order to learn"

I think I’ve had the conversation with new to my organization devs a few hundred times: “Look... saying code is crap or stupid is telling others you’ve given up on learning. How about asking why it is the way it is?”

> greatest failings I've seen in leadership in our time is the idea that in order to make a critique one must come with a solution in hand.

The pattern works at very high levels in an org chart, but with developers and those that manage them it breaks the whole concept of problem solving. You have to be able to identify and understand problems before you can come up with a solution... and usually, with software, the solution is developer hours.

I always pick apart previous teams' work.. it's how I learn. I question most every decision because I'm curious why they made those decisions. And it lets me think about how I'd do it better. And yes, I know that many poor decisions are not necessarily the developer's fault. It could be bad specs, lack of time, etc.

In most cases, "better" means different things in different contexts. (Customer-driven vs performance-driven, for example) Of course, this isn't news for most of us. Where I think a lot of us fall short is assuming that definition has changed since the code was written.

This harkens back to Chesterton’s Fence. It’s always worthwhile to interrogate why things were done the way they were, especially when first coming onto a project. Knowing the why of a decision is essential to understanding if and how it should be changed. Especially if the reason is “this is what we had the time and knowledge to do at the time.”

The people who have those answers have long gone. The only person left is a project manager who tells you it's up to you to figure it out. After you make a change in production they will come to you with questions after a few months, just when you assumed things must have gone well

> It’s always worthwhile to interrogate why things were done the way they were

It really isn't. A lot of the time you end up spending a lot of effort to understand something that was dumb to start with and has been dumb ever since. Something like the bullshit asymmetry principle applies - any idiot can take 5 minutes to write a line of code that will baffle a team of experts for hours. (I've done so often enough myself).

They usually shut up when they realise the "previous team" was one of the founders who is paying their wage.

When your v1 code takes a company to profitability it was good enough.

Oh man this one hits home. I don’t do much coding anymore but my general advice to folks I lead is you’re never going to be happy with how you did things and just make sure it scales and is well tested.

So true!

Fred Brooks has a whole chapter, 'The Second System Effect', on this in 'The Mythical Man Month.'

"The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."

Brooks reasons that the combined experience of doing the first project well and the second project badly leads to better designs from then on.

And the only better experience than that is that all software is pain

At this point I just don't think total rewrites from scratch are a good idea, full stop. I've never seen a rewrite from scratch that didn't lose most of the learned solutions from the previous attempt, repeat most of the same mistakes and have to re-discover the solutions, and utterly fail to even attempt a passable improvement on a model of the core complexity of the problem being solved.

I'm not granting a "rewrite from scratch in Rust" exception even though that's in vogue right now. I'm not saying don't rewrite it in Rust, I'm saying don't rewrite it from scratch. It's harder to write new features in Rust while maintaining the old C code, but it's the right way to do it.

AKA fighting the last war. Can be difficult not to focus on trying to avoid painful things from past projects, though.