3 ms·

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked ho

by jshen 3y ago

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.

bambax 3y ago
It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
- jshen 3y ago
  That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
eikenberry 3y ago
This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times. The fix for this is pretty easy though. Keep employees and avoid the churn.
- jshen 3y ago
  Yes! See my reply to the commenter above you.

by jshen 3y ago

bambax 3y ago

It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.

jshen 3y ago
That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.

eikenberry 3y ago

This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times. The fix for this is pretty easy though. Keep employees and avoid the churn.

jshen 3y ago
Yes! See my reply to the commenter above you.