Chief
Related Posts
Additional Posts in Software Engineering
Rising Star
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.
That was just a preview…
Sign Up to see all discussions
Sign Up to see all discussions
- Discover what it’s like to work at companies from real professionals
- Get candid advice from people in your field in a safe space
- Chat and network with other professionals in your field
Sign up in seconds to unlock all discussions on Fishbowl.
"" is an unusual email domain. If correct, please proceed to the next step
Messaging rates may apply
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
New to Fishbowl?
Download the Fishbowl app to unlock all discussions on Fishbowl.
Share
Embed this post
Copy and paste embed code on your site
Preview
Download the
Fishbowl app
Scan your QR code to download
Fishbowl app on your mobile
Sign up for free to view this conversation on Fishbowl
Sign up for free to continue using Fishbowl
Messaging rates may apply
I think the art of building systems capable of adapting to change has diminished over the years. There’s pressure just to keep shipping, which means logic ends up hard-coded and intertwined and making it impossible to make substantial changes without breaking the core logic.
Chief
That pressure to keep building and delivering value is the impetus of what causes these brittle systems that need replacing
Yes. It has. There are a number of patterns that I've noticed that seem to be influencing this trend (some are valid some are... really stupid reasons... but nevertheless very real). Here's some that I've seen:
1. Market consolidation on specific skills (e.g. VERY difficult to set up your own compute clusters because most of the experts got absorbed into AWS/GCP/Azure).
2. Businesses are pushing for fast delivery, pressed to cut plenty of corners leading to brittle software.
3. Businesses are aggressive on cost reduction... so they force juniors and mid level engineers to make "architecture" decisions because they can't afford experienced seniors. So the juniors get a field promotion and are incentivised to deliver on the compromises their employers make with nobody to talk sense into them.
4. Genuine paradigm shifts seem to be happening more frequently (new frameworks, new technologies especially in my space of ML/AI) - so businesses are pivoting more frequently to react to market changes in technologies.
5. Higher employee churn. Businesses stopped valuing employees that have worked for years... they didn't hold up their end of the social bargain... so people leave. Meaning the remaining systems are critically unstaffed... so sometimes it's easier to state afresh.
6. Staff stick around less often. The less I have to own and maintain and debug some code, the less care I will put into making it in the first place.
7. There's a tendency for people to join a new team and immediately call the old code as bad and suggest they build it the way the new guy wants it built. Because that's easier than to understand someone else's code. Rarely do they just join and accept the current situation and observe first before pointing out flaws.
Chief
What a comprehensive list!
I would add that, in addition to the social reasons others point out, there's a technical reason too. Software these days is usually not built on a language and standard lib alone, but on a long list of frameworks and dependencies. If a framework like React or Spring stopped shipping new major versions, they would quickly fall into obscurity and be perceived as outdated. In addition, they can only back port security fixes so far. This gives them an incentive to keep updating and not support your "ancient" version.
There's this idea of coldblooded vs warmblooded software. Coldblooded software you write once, and it works with minimal changes and maintenance for a very long time. Warmblooded software can give you advantages cold blooded software can't (usually by supporting more modern features), but it requires constant upkeep and energy. The difficult part is, when your dependencies are warmblooded, your software must be warmblooded as well to keep up with the dependencies (and close any potential security risks). So if you work with a framework with a 6 month release cycle, guess what? Your own application is going to need a release cycle on a similar order as well, maybe you do every other version, but you still need constant maintainance.