Hacker News Reader

Comment by DarkCrusader2 | Hacker News Reader

I am in the exact opposite,but equally frustrating boat.

In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead and if you still insist to refactor and modernize and something goes wrong, now you are personally responsible for the outage. The effort you spent successfully upgrading decades old stack won't count in your promo packet.

There is just no incentive to upgrade anything beyond security fixes. Rewrite to chase the latest fad is frustrating but using technologies which don't even have online documentation anymore is equally if not more frustrating.

View on HN

I was stuck maintaining a solution using an abandonware internal transport layer built on technology that died in 2004 and an abandoned ORM on an EAV schema database over SOAP backend in 2022 with much the same "no business value in it" argument. "We're trying to sell the company so profit is of the most importance" transitioned into "we bought you because you make money". So instead we increased our maintenance exposure by adding more necessary features to the wobbly pile (or 'fixing' broken ones) as opposed to resolving the mistakes made over twenty years ago.

Of course the dickhead architect would use articles like this OP as justification for why all of this wasn't a problem.

The way that I have avoided burnout for all these years is working on my own projects, and building them exactly the way I want to. This gives me the strength to grind through the shitty work I am paid to do.

Maintaining old stuff is way more sensible than rewriting everything every few years. Companies tend to measure costs of maintenance vs rewrite.

Edit: there's always a tradeoff but I wrote "every few years". Cobol is an odd example. Many banks have been going back to Cobol because they found it less expensive than the alternatives and are there is an influx of new graduates learning the language right now.

Up to a point, there's always a tradeoff and a turnover point; at the moment the old Cobol mainframes are one of those; the tradeoff is that there's a lot of institutional knowledge and essential processes in that code, but on the other it's harder to find competend staff that can - and want - to work with it.

Sensible for who? Companies may try to estimate costs of maintenance vs rewrite, but individuals need to make the final call and for them the benefits usually go the other way.

Maintaining some existing project is going to get you nothing if you do it right and will bring you problems if it breaks despite your best efforts. Rewriting an existing system in a new tech stack counts as exciting innovative work for promotion purposes, or at least prepares your CV for your next job hop. With salary bumps between levels being what they are in software, I'm not surprised people choose the more lucrative option.

A stack that goes down all the time is a ripe opportunity for career advancement, if you are in to that.

Hell, I have seen the creators of the problems get endlessly promoted for constantly solving problems they created.

Small or medium company, critical systems going down a lot...give me that shit. Easy money and reputation.

news flash: You are working in exactly the same place.. it is just 5 years later :-) All that outdated technology you mention, was probably introduced as the newest-cant-live-without at some earlier time.

So how old does the tech need to be?

It doesn’t matter as long as it is consistent and maintained.

I’d say at least 5 years since it’s debut.

Long enough for the rough edges to be softened, to show that people are willing to maintain it, for detractors to have pointed out legitimate issues, for the tech to become stable.

I’d prefer 10 years personally, but I value stability more than most. I dislike revisiting problems I’ve already solved.

The hype train never stops! The golden ticket is for the front cabin but ideally you are driving it.

The older the better.

The better understood, both in capability and limitation.

The better chance no new updates will break it.

The better chance no new updates.

The better you get to know it.

The better you get to integrate it.

The better the chance it will be there tomorrow too.

The better the investment learning it becomes.

On the opposite end of the spectrum, if your stack is too old (and niche enough) then you won't get to know it very well once every bit of documentation was hosted on expired domain name, and you can only find bits of online discussion about it are Internet Archives snapshots of a forum long since dead.

And also you don't get to integrate it very well if everything around it isn't maintained, and compatible on old version of a library (with said documentation not existing anymore).

Also, while resume-driven development is not a good thing either, it's certainly not a good investment to pigeonhole your career into working with something you hate working with.

> The older the better.

But remember to use the right tool for the right job - older isn't always better. E.g. there is a set of people who use stored procedures for everything and it does make sense when you are doing data-heavy processing on database-side. But using that for everything, even when the volume is absurdly low, is a bad idea - using a language like Java would be a million time more flexible, composable, testable (unit tests, anyone?) and allow making changes with greater confidence.

PHP old

It's a weird tradeoff between innovation vs reliability, investments vs cost, but also, staff retention & hiring. I think a lot of companies follow fads as a way to attract talent. It's not in their best interest to follow the fads or spend time rebuilding the same thing over and over, but otherwise they'd run out of competent staff and are left with low energy / "safe" developers.

Competent staff = magpie devs?

In both of your cases, I think there is this massive disconnect in decision making. Software development is a constant game of economic decision making. Which investment returns the greatest value. Agile worked because it spread risk and allowed for reaction to new opportunities.

CICD/devops worked because it drastically reduced the risk & expense of defects, the cost of development, time to market, etc.

But the chasing of new technology fads vs lagging behind with old outdated technologies? I am seeing people make decisions without thinking about the decision.

What economic benefit does the new tech bring? Whats the economic trade off of implementing it vs other projects? How long till a return on investment? Whats the costs if we do nothing?

It isn't even that hard to do, but people just keep deciding to spend time and resources with little to no thought. It infuriates me.

If the way people allocate resources makes no sense, you are likely missing information on the returns they're getting from it.

"Agile worked"

Citation needed.

The decision makers themselves are couchsurfing.

You'll consistently notice obviously idiotic decisions rooted at decision makers who aren't around to own up to the mistake.

The other end has decision makers never change, they waited too long, were too risk averse to stagnate and the cost of change just keeps rising.

The ones who end up surviving this churn, have both kinds of decision makers in equal powers, mistakes are made, but things keep moving sometimes in leaps, sometimes backward steps.

Congratulations. It sounds as if you are working for a company that knows what it is doing. They are clearly focusing on customer value instead of chasing the latest shiny new but buggy and gone tomorrow “new” tech. Giving you an opportunity to focus on delivering value to customers in a stable environment. Making each delivery higher quality and less buggy than the previous.

I work in such an environment and routinely deliver million+ line applications with ZERO bugs in production to very large customers around the world. Highly satisfying.

Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.

Not my observation sadly. We've got some excellent 10+ years old tech -- Golang, Rust, Elixir -- yet a lot of companies out there holds on to C#, PHP and Java with an death grip.

And I've worked with all of these. The newer stuff is better in every way except penetration (which is held back by bias and misguided evaluations of the word "safe").

I wouldn't put C# and Java in the same pile with PHP as bad tech and Go against them as good tech.

I would, when it comes to parallelism. Java being stuck at OS threads (I know about Loom but it's nowhere near the BEAM VM or goroutines) is not doing it any favors.

PHP at least attempted some isolation between requests (emphasis on attempted) even though it didn't do it very well.

All that being said, people don't like seeing their favorite tech called out and the kneejerk down arrow presses are expected. Programmers are a tribal bunch.

Personally I've found my productivity multiplied with the above-mentioned more modern tech: Elixir, Rust and Golang. But I am also aware many companies would never risk it, and that there is no shortage of people who are OK coasting on old stacks if it pays the bills. Not judging.

Sounds like such a place could have really nice documentation.

really surprised faang management doesn't see the value in addressing technical debt.

Move fast and break things has downsides that get to be paid some years down the road.

Because they don't see technical debt as a bad thing. Go back to the original pitch for technical debt by Ward Cunningham. He was working for a finance company and used the debt metaphor to advocate in favor of "borrowing against the future" when implementing new code. The idea was that you could use the latest stuff without reinventing everything. Like mortgage payments, the reinvention could happen over time, in increments, until it's "paid off". The problem is that nowadays, especially in finance, you're dealing with people who are used to over leveraging everything. To them, the idea is to pile on debt until it becomes unmanageable: and then sell. Or go into Chapter 11.

Rewriting an application will usually simply give you a more buggy app with less features and more technical dept. At a high cost.

Smart businesses and developers instead step-by-step refactor and upgrade their existing apps.

Reply on news.ycombinator.com