Comment by jimbokun
8 hours ago
Humans who have been writing systems like that for many years know how to maintain and modify them successfully. It’s just that our industry has a bias towards youth who don’t think they have anything to learn from those who came before them.
How do you explain to a junior this pile of messy code isn’t crap but is actually years of integrated knowledge ? That the most common principles discussed in computer science (OOP, SOLID, DRY etc.) are actually just little guides that aren’t to be taken to the extremes ?
Here's a 26-year old post on the exact topic of messiness you raise:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
A decade ago, I was sitting in on a meeting about a rewrite and, before I could say anything, someone in the first year of her career asked why anyone thought a rewrite would be any cleaner once all the edge cases were handled. Afterwards, I asked her where she learned this. She said "I don't know, it just seems kind of obvious." She went on to be a great engineer and is now a great manager.
I work on internal facing software and every rewrite I've seen in 20 years suffers from the same symptoms. The code/system is a mess because it has been exposed to reality for a decade. Reality is messy. That's why they pay us money, believe it or not.
Greenfield guy comes in, promises the world, and starts from some first principles white papered architecture. It's really lovely until they onboard the first user. Then they slowly commit all the "sins" (features that drive revenue) of the first system.
The firm is stuck supporting N systems indefinitely because the perfect new system takes so long to cover even 30% of the original system use cases, that management takes a flier on.. bear with me.. a second rewrite. Now they have 3 systems.
I've seen more 3rd systems than I've seen actual decommissioning of original systems into a single clean new system.
The answer is chipping away, modularizing, and replacing piecemeal Ship of Theseus style. But that does not drive big hires and big promotions.
The bolded quote "It’s harder to read code than to write it." is hilarious given todays context... it has only become more true :)
It's a dice roll to keep the junior around until he unlearns the wrong bits.
Expert knows when to break the rules
Experts take the time to learn why the fence was there in the first place.
2 replies →
tell them they need to turn a profit as quickly as possible
Wait if they can do that they’re not juniors anymore :P
> Humans who have been writing systems like that for many years know how to maintain and modify them successfully.
Do they??
Yeah... in my experience people who code like that 'successfully' make modifications that fix an immediate problem while kicking another bug or two further down the road in a never-ending sunk-cost-fallacy of job security...
Yes.
There is a lot of absurdly complex software that runs with high reliability. We hear a lot about the ones that don’t.
I believe this type of person exists.
My team lead has worked on the same software for 30 years. He has the ability to hear me discuss a bug I noticed, and then pinpoint not only the likely culprit, but the exact function that's causing it.
I do the same thing in a project I’ve worked on for 25 years. I’ve had mediocre at best results with AI. It’s useful to discuss concepts with, but the code never handles the nuances of the edge cases.
Then they quit or die.
9 replies →
This is sadly so true.
I have really tried as an "old" person in the field to try and pass on the stuff I've learned, but "craft" and such really has absolutely no home in modern dev culture. The people who care about history, the craft, etc. are increasingly rare.
Executive leadership bias older not younger, no?
No.
Younger implies cheaper.