6 ms·

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 out

• Quarrelsome 3y ago
  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.
• mathgeek 3y ago
  Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.
  • pdimitar 3y ago
    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").
    • oblio 3y ago
      I wouldn't put C# and Java in the same pile with PHP as bad tech and Go against them as good tech.
      • pdimitar 3y ago
        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.
• goodpoint 3y ago
  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.
  • Cthulhu_ 3y ago
    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.
  • WJW 3y ago
    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.
    • datavirtue 3y ago
      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.
    • deleted 3y ago
      [deleted]
• Cthulhu_ 3y ago
  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.
  • grugagag 3y ago
    Competent staff = magpie devs?
• dicroce 3y ago
  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.
• fnord77 3y ago
  really surprised faang management doesn't see the value in addressing technical debt.
  • grugagag 3y ago
    Move fast and break things has downsides that get to be paid some years down the road.
  • ncphil 3y ago
    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.
  • deterministic 3y ago
    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.
• fifticon 3y ago
  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.
  • throwuwu 3y ago
    So how old does the tech need to be?
    • grugagag 3y ago
      It doesn’t matter as long as it is consistent and maintained.
    • falcolas 3y ago
      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.
    • 6510 3y ago
      The hype train never stops! The golden ticket is for the front cabin but ideally you are driving it.
    • dusted 3y ago
      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.
      • mablopoule 3y ago
        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.
• 6510 3y ago
  Sounds like such a place could have really nice documentation.
• manvillej 3y ago
  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.
  • namaria 3y ago
    If the way people allocate resources makes no sense, you are likely missing information on the returns they're getting from it.
  • datavirtue 3y ago
    "Agile worked" Citation needed.
  • gofreddygo 3y ago
    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.
• deterministic 3y ago
  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.