[calebpeterson]

I once had a manager that was fond of saying:

> Experience is what you get when you don’t have any.

The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.

[namdnay]

And the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)

[pjmorris]

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.

[fjjjrjj]

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.

[gorbachev]

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.

[beoberha]

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.

Edit: oh and how could I forget as simple and readable as possible

[kerkeslager]

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.

[jcheng]

Second System Syndrome! :)

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

[rcxdude]

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

[purplethinking]

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

[calebpeterson]

So true!

[atoav]

I always tend to say: "Everybody learns better from their own mistakes, but if you are empathic you can also learn from other people's mistakes".

The latter is less costly and only requires you "only" to open your eyes and look at projects that are in an ugly state the right way. Yet surprisingly few people are capable of looking at someone elses fucked up project and not going all like: "Hah! Idiots! I would never have made that decision".

Maybe however that crusty piece of code used a framework that — back in the day — was the hottest, trendiest piece of technology out there and you are currently in the process of committing similar sins, and you won't know it till it is too late.

For me adminstration of Linux servers has been an invaluable source of inspiration. You are directly and 100 percent exposed to the effects of software aging in a changing environment. And you directly wittness which software ages like fine wine and which ages more like milk.

[globnomulous]

> which software ages like fine wine and which ages more like milk

Now I'm curious. What software has aged well? What software hasn't? Do certain types or categories of software tend to age better or worse?

[pavel_lishin]

Especially when they're your decisions, decisions you pushed for and felt very good about at the time.

[calebpeterson]

Yep!

There is no teacher quite like cause and effect.

[regularfry]

This is literally the approach recommended in Team Topologies. The same team should own vN and vN+1, so that they both have to operate their own design and have the opportunity not to make the same mistakes again. It should be the default.

[rafaelmn]

That would require staying in one company for more than 2 years, which means you probably lost out on 20-30% of income over next 2 years.

[pz]

In particular, I appreciate that you assign value to the consequences and not the decision itself. Anytime junior engineers on my team would complain about "shitty code" I'd assure them that someone would be complaining about their code in a few years.

Having the context or, better yet, responsibility for the past decisions is great for developing a pragmatic approach to software design AND empathy for other software engineers.

[ixtli]

Came here to say this. Ive had to work on slop, and it never stops being slop unless the stars align and you can do a bunch of work which is short term unprofitable. What people really should do is work on the same project for five years. Watch the interest wax and wane and more importantly watch the requirements change. Then you'll stop looking at things in black and white like "good project bad project"

[softfalcon]

Too bad a lot of devs love to greenfield, slap it together, then bugger off to the next project pronto.

[lmm]

When that's both more pleasant and better paying, who can blame them?

[svachalek]

"You either die a hero or you live long enough to become the villain"

[calebpeterson]

Never thought of that in the context of software projects. It works really well!

[konfusinomicon]

oh the hills that were conquered and those to have died upon, captain hindsight strikes again!

[hinkley]

Come on to a brownfield project and ask a lot of pointed questions about how we got here.