Boring tech is mature, not old

Remembers me of https://www.joelonsoftware.com/2000/04/06/things-you-should-... : "All new source code! As if source code rusted."

I experienced this few years ago. I was hired with a team of consultants (I know.. I know..) because the system in question would have data randomly disappear from their databases every few weeks and it would take the operation team a month to notice, so by then the issue was harder to rectify.

The engineering team in question had proposed to rewrite an old Java app with AWS Amolify and replace their Postgres database with Dynodb. The whole thing was then ducktaped with Lambdas and spread across multiple regions. They had not bothered writing a single line of test, never mind having any kind of build and deployment pipeline.. they didn’t even have basic error reporting.

After doing a deeper dive, we discovered that engineers didn’t have a local environment but only had access to staging, however they could easily connect to the production database from local by just updating environmental variables. It turns out that one of them had forgotten to switch it back after debugging something on production from his machine and had forgotten to switch it back.. he had a background cleanup job running in intervals which was wiping data..

It was a complete nightmare, the schema less nature of Dynamo made it harder to understand what is happening and the React UI would crash every 15 minutes due to an infinite loop.

The operation team had learned to use the Chrome console and clear the local storage manually before the window feeezes..

Being charitable, in order for one of those new technologies to become mature and boring it requires guys like that to actually use it for things. So while it might be misguided we thank them for their sacrifice of getting caught on every sharp edge so they might be dulled (or at least documented) later.

> Greenfield rewrites of a multi-decade old app

It depends on what you mean by "multi-decade old app".

Excel is a multi-decade old app. Windows is a multi-decade old app.

They're both still being actively developed with a lot of new and cool features added though, and that keeps it fresh.

The multi-decade old app that hasn't been touched in 20 years? It need a rewrite. And yesterday.

I suspect though, that is not what you meant.

I can, off the top of my head, name at least half a dozen of "those guys" and describe in detail the wreckage they left behind. Including one that was a major contributor to an 80%-of-the-billings client finding an alternative agency resulting in almost 100 people losing their jobs. :sigh:

Your phrasing implies that the Greenfield rewrite is always a mistake.

Depending on the project, it might actually be the only sane option if you're still required to make significant changes to the application and features have be be continuously added - and the project has already become so full of technical debt that even minor changes such as mapping an additional attribute can take days.

As an easily explained example for such: I remember an angular fronted I had to maintain a while ago.

The full scope of the application was to display a dynamic form via multiple inputs and interdependent on the selected choices of the available form (so if question 1 had answer a, question 2+3 had to be answered etc).

While I wouldn't call such a behavior completely trivial, on a difficulty line it was definitely towards the easy end - but the actual code was so poorly written that any tiny change always led to regressions.

It was quite silly that we weren't allowed to invest the ~2 weeks to recreate it

Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well.

But yeah, lots of Greenfield rewrites end in disaster. I give you that!

I have a lot of respect for anyone doing this, as someone who also had to work for a living.

Same as I have for people resisting it because they want stability.

It is the management’s job to handle this decision and any potential problem caused by it, period.

Modernization can mean replacing 50 year old technology with "20 year old" technology. I stuck in the quotes because something that is perceived to be that old is probably under active development, and modern while remaining boring.

Actually seen a ton of this from mid-career people who should know better but don't (or don't care). New grads aren't leading Greenfield multi-year projects.

Yeah, Resume-Driven Development is unfortunately such a common methodology and companies indirectly push for this by punishing candidates who admit to doing maintenance work and bug fixing instead of rearchitecting everything every year.

the incentives are towards learning the shiny new tech, a FANG company created,so you can get a job in one of these companies

The only reason to ever use a non-relational db is for scalability and performance reasons. Joins and transactions are hard to do correctly and efficiently in a distributed system. So “NoSQL” solutions can be a good fit if your data is too big to fit on a single host and you can get by without joins and transactions.

(This is a massive oversimplification, but still used rule of thumb.)

I think it is important to point out that boring tech is not Java 8 or .NET 2.0 that some companies are stuck with.

There is still lots of interesting stuff if your company uses newest Java or newest .NET but both are „boring” in a good way so mostly stable and changes to those are incremental and progress is stable.

Heck Angular with its latest improvements in v17 and v18 is quite interesting - but counts as totally boring and stable tech. Migration to signals and standalone components is a bit of a hassle but still is rather easy.

At one point you need to admit Linux knowledge is unnecessary, beyond the basic cd/cp/chmox. Docker replaces it. Should I choose init.d or SystemD? None, just launch a new container.

> What they don’t understand is that after 10 or 20 years of this drama you start to realize how much of this new shit is a repetition of the shit the “old shit” replaced

That happens, sure, but all too often these same greybeards will fail to recognize when there is a truly novel thing. So do give new tech an honest chance before writing it off as reinventing the wheel.

> absurdities like "show HN: I built a rust backend with an elixir front-end that's actually running doom in pdf hosted on a distributed server composed of a network of the microchips in a Saudi camel herd, get fucked nerds"

You leaned too far into the joke and it undermined the point. There’re roughly three kinds of Show HN:

1. “I made this product to solve this need I perceived. I hope it does well and makes me money. Come check it out.”

2. “I had this insane idea which is funny just from the description and made it as an experiment. Let me share what was interesting about it. Oh, and here’s the code.”

3. “I made this AI NFT Data Harvesting scam and think everyone is too stupid to notice this isn’t a real product filled with fake reviews. Come click this link from this account with 80% flagged comments.”

What you described seems closer to 2 than anything else. There’s nothing wrong with those. They stimulate curiosity, which is HN’s goal.

Every hobby seems to have a contingent of people that are more into the gear than the activity itself

I've seen this happen across so many hobbies to so many folks.

Easier to geek out over the gear and/or spend the cash than to do the hard work and take the time to actually, you know, do the hobby.

But the nice thing about carefully designed products is that they can be built by people who don’t care.

Not sure if that’s possible when building software systems.

No, but when your drill breaks there's still plenty of potential for it to physically injure you in different ways. As mooreds said, the end user doesn't care how you made the tool, they care that it won't go catastrophically wrong on them. How you accomplished that is not relevant.

This sounds wrong. Most popular and with most questions languages are likely Python, JavaScript. These are not exactly new.

Wat.

First, I want to see numbers to back that up. New versions bring new bugs that aren't known yet, by anyone. Old versions have older, more widely known bugs. From a stability POV, sticking with the old may be good: you know how to work around the old issues. From a security POV, that's probably bad: every script kiddie has a Burp Suite plugin to exploit it.

Second, there ain't no such thing as an immune system. You can asymptotically approach zero, like you can approach the speed of light, but it would require infinite resources to reach either.

Apologies on missing this yesterday. I would add that saying it is "boring" with regards to "stability" means I also trust that what I learned about it last year is largely still relevant today. May not be cutting edge relevant, but is unlikely to bite me by being flat out wrong.

"Boring" works in this regard because you are saying there is not a lot of activity behind the scenes on it. Most of the work is spent doing the "boring" parts of the job for most of us. Documentation and testing.

Or maybe they could have made the standard lib better, then? There is zero point to such a "dependency".

Dependency conflicts become an issue for large projects in any language. It's less of a problem when the language's runtime is feature-rich since libraries will be less likely to use a third-party HTTP client. You can choose libraries with fewer dependencies, but that only gets you so far. At some point, you can put the libraries in you monorepo, but upgrades come with a large cost.

Yeah that is a nightmare. But isn’t that a problem on all package systems except more dynamic runtimes like NPM which can load many copies of the same library?

Yes, I don't curl|sh like recommended for my rustc or otherwise install random arbitrary compilers from outside of my OS repositories. I have an OS install with system libraries and programs and I want to use that.

I don't have to set up a custom install of a language for every single application for any other language (although python in machine learning domain is getting there). This is an abnormallity which complicates software mantainence and leads to problems. It should be avoided if possible. And setting up container for every application is also not a solution. It's a symptom. Like a fever is a symptom of infection, containers are symptom of development future shock.

To be clear, I'm talking about in the context of a human person and a desktop computer. Not employed work at a business.

I would love to see a metric of the number (or proportion) of issues closed even though users are trying to get assistance. No idea how to make that machine-calculable though.

Even better, a metric for refused PRs (maybe including PR size somehow), tracking where users cared enough to try to contribute and the owner just refused to accept the changes. Easily gamed though.

Yeah they're definitely out there. Looks like there aren't any active forks either. Bummer. I had another really good example of one that was super popular but I can't remember what it was.

Here's some requirement sections from real frontend job postings on weworkremotely.com. Not putting them all here, but I clicked through a dozen and these seem representative.

Except for the mentions of next.js and one mention of AI assistants, these job postings could be from 2020 or even 2015.

    Senior Frontend Developer at SimplyAnalytics
    - 8+ years of professional software development experience on large, structured code bases using vanilla JavaScript (this is not a React, Angular, Node.js, or     full-stack position)
    - Strong UI development skills (CSS & HTML)
    - Open to learning new technologies
    - Self-starter who gets things done
    - Attention to detail

    Frontend Developer at Nutrient
    - Good knowledge of web technologies (e.g., HTML, CSS, React.js. Next.js, Javascript/jQuery, HTTP, REST, PHP, Cookies, DOM).
    - Familiarity with UI frameworks (e.g., Bootstrap, Tailwind CSS).
    - Familiarity and regular use of AI assisted IDEs like Cursor, Windsurf, Co-Pilot, etc.
    - Manage and prioritize multiple concurrent projects, meeting deadlines in a fast-paced environment.
    - Have good communication skills and enjoy working with a passionate team and experience working on a globally distributed team.
    - Have a well-rounded approach to problem solving, and understand the difference between when to apply a fix and when to refactor to remove a specific class of bugs.
    - Experience integrating with various Marketing technologies and tools/APIs (e.g., Hubspot, Google Analytics, Salesforce, etc).

    Senior Frontend Software Engineer at Hopper
    - Senior-level experience & familiarity with React
    - The ability to effectively drive towards a solution in a thoughtful and creative manner
    - The ability to work autonomously,  iterate on solutions, and manage different contexts
    - Dealt with ambiguity and can balance building out multiple features at once without jeopardizing the quality of the code

    Senior React Developer at SKYCATCHFIRE
    - Expert-level React development
    - Strong background in TypeScript and Next.js
    - Using AI assistance tools to develop better software
    - Experience building and maintaining large-scale applications
    - Clear written communicator that prefers emails to meetings
    - Portfolio showing systematic, well-structured work

Maven is so painful, though. Isn't Gradle an improvement on Maven?

Is your assumption that the learning curve on Gradle is higher than that of Maven?

I ask as someone who endured both tools/ecosystems and is intrigued with the idea of moving on to a system like Bazel.

Yeah, and if Google hadn't used Go themselves, it would've also fizzled out.

Any halfway non-horrible tech just needs enough funding and usage from some company to become mainstream.

Most professional photographers use autofocus all the time.

Photography is less about the technology and more about the art.

I think that's the biggest difference between SC 1&2, although the former is still being nudged a bit through map design.

SC2 in its first decade has been about always keeping the game fresh - new units, new spells, adventurous changes, crazy maps. As of 2020, the changes not only stopped, but the game was caught for a few years in a pretty crappy state: nigh unbeatable PvT cheeses, 40min-long PvZs where Zerg is clearly winning but can't close the game, meanwhile no Protoss in top 10 GM or major tourney semifinals. The worst of it has now been fixed, but the changes are only slight tweaks and nudges, now again reminding me of Brood War. It's still an excellent game though.

True, they are not done and moving. But what you did with them 20 years ago still works today. And what you do with them today, likely still works in 20 years. Exceptions obviously exist, though.

The major changes in web development landscape:

- IE9 which finally allowed you to use modern (at the time) web features (like flexbox) without having to support IE specific hacks.

- ES6 which added a lot of syntax changes to JS to make it much nicer to use (and pretty much killed Coffeescript).

- Popularization of type-checking with Typescript and Flow around 2020 which is almost standard these days.

And of course the frameworks evolved a lot as well, but that was mostly project-specific not so much the platform. Someone doing React doesn't care about Angular2 release.

Don't forget to break it into microservices