The thing I find most frustrating about “The Boring Revolution” is that it feels stuck in the particular year of 2015. Like, React has been out for 12 years. React is older now than Ruby on Rails was when the Boring essay came out. And yet I still hear people talk about React as this “shiny trendy thing”, even though it’s a mature technology with huge adoption, mountains of examples and documentation, and millions of developers with years of experience building in it.
If the essay had come out in 2008, Ruby on Rails would’ve been the “exciting” thing it was calling out. But instead, Ruby on Rails is generally considered in the “boring” camp, while things that came out closer to the essay’s publication like React are in a state of “Permanent Shiny”.
All of which blinds people to the fact that the web space has in fact settled down years ago and is not in the state of immense flux that actually was happening in 2015.
React to me will always feel like Java - a big solution by a big company for solving big company problems. When it is forced on small problems in small companies it creates unhappiness, yet, choosing something else feels like the "no one ever got fired for choosing IBM / Microsoft" dilemma.
React isn't big, it's about as small as a "framework" gets. The problem most people face is actually that the simplicity gives the developer unlimited freedom to craft whatever complex monstrosity they desire.
You haven't used vue 2 or svelte then. Modern React is big and opinionated (just like Angular). When people talk about react they are not just talking about a state management library anymore
Vue and Svelte are just as complex as React, I'd argue Vue often ends up being even more complex than react even though the barrier to entry is a bit lower for novices. If you disagree, I encourage you to link to a mature project on github built with svelte or vue that you regard as an example of simplicity.
That's exactly what I said. React is so simple and flexibile that it leaves a lot of room for developers to shoot themselves in the foot. The C analogy is spot on.
There are plenty of "newer" technologies that closely mimic more "boring" tech too. For example, Svelte feels a lot like writing vanilla HTML and JS, Supabase is all built entirely on PostGRES instead of a shiny, noSQL database.
To reduce "the boring revolution" to a React aversion is a bit dismissive.
"Boring" is malleable. If your team is full of React experts, React is boring.
If your team is full of backend-oriented engineers who rarely deal with the frontend, React is much less boring.
"Boring" is also not binary; it is continuous. The mix of technologies in your stack culminate in some arbitrary measure of boringness. This measure can also be thought of as the degree to which teams choose cutting/bleeding edge technologies. If the mix is mostly cutting/bleeding edge, it's very likely that production support is not boring, and problems operating the stack in production are not boring.
Choosing boring technology is also not a panacea that solves every team's problems. Although doing so likely mitigates them.
I'm not really sure how you expected the mantra of use mature technologies that are stable, mostly unchanging, and have staying power could have turned out any other way. React Hooks which required a partial rewrite for every code base happened in React 16-17 which was in 2020. This is neither a boring or stable technology to build a business on. This doesn't mean it's bad but it doesn't survive the "I can pick the code up after a few years and get it up to date with minimal effort" test.
Write boring code is about going down paths that are well troddened enough that they paved a sidewalk which isn't going anywhere any time soon. Most of the frontend world can't even conceive of an LTS release right now.
I genuinely don't understand the author, choosing boring technology is about making choices so that that platform on which you stand is rock-solid. It's easier to exercise fun, creativity, and new ideas on such a platform because there aren't any sharp edges and you can start pushing a technology. The examples with introducing Kotlin or Python/PL seemingly aren't motivated by anything other than "they're new." What problem are they solving and do you have that problem?
I don't know in what company you work at. But you can't have outdated libraries in production forever. Vulnerabilities happen. Stable does not equate outdated. Look at .Net. You can pick a codebase from 2014 and make your way around easily. It is like home. Similarly, your 2014 dev could jump into a time machine into 2024 and work with .Net Core easily. Also, 2014 codebase can keep getting the latest security patches without having to rewrite the codebase.
That's not the case with React or most of the js frameworks
.net??? I worked with .net for about 10 years and over multiple versions of .net and .net core, the amount of time we spent facilitating upgrades was much more than I ever spent on upgrading a react app. In fact, at my last .net job I was hired specifically to transition the company's platform from .net to .net core. There was so much work involved that they literally created a role for it.
> If your answer to how to make it stable is never update then you're not working on a stable technology.
I didn't say "never update", I said that if you don't need the new features then don't upgrade. If you do need the new features then I don't understand what the problem is.
> Stable is being able to set up unattended upgrades on Ubuntu fearlessly.
lol what? I've never had a system survive an Ubuntu upgrade without breaking something.
Point is many of these libraries don't just let you get latest without rewriting some of your code. Multiple that by 10-20 and you are in for a real treat.
> Point is many of these libraries don't just let you get latest without rewriting some of your code.
True of every software platform in existence.
On the scale of upgrade complexity, react is a walk in the park compared to e.g. everything in the android and ios world, or e.g. any application written for a desktop platform. Ever tried upgrading a C++ app? It's a nightmare beyond anything I've ever faced in my career.
I've never worked with Rust in a professional environment, but I've been a big fan of it for my personal projects for some years now, however, the introduction of async was a massive disruption to the entire ecosystem.
In my opinion, complaining about JS complexity in particular reflects ignorance of the wider software world.
Well yeah but Rust isn't a boring technology and C++ has
its own reasons for being difficult. The goto examples of boring are C (and Objective-C), Java, Perl 5, PHP, Vanilla JS (the browser itself is remarkably stable), Rails, Django. Just a who's who of ecosystems people don't want to program in.
Perl code doesn't work today just as well as it didn't work 20 years ago.
Yep patching Ubuntu is so stable it's fully automatic and upgrading to the latest Ubuntu is 1-2 days work. Getting to the latest on our front end is a project.
It's easier to exercise fun, creativity, and new
ideas on such a platform because there aren't any
sharp edges and you can start pushing a technology.
Yeah. I don't interpret "use boring tech" as "literally don't use anything newer than 10 years old" or whatever.
You absolutely can/should/must use more exciting things if they are relevant to whatever unique problem you're trying to solve.
But everything else possible in your stack (particularly foundational elements) should be as boring as possible - i.e. unless you are specifically innovating in the area of RDBMS systems, you should be choosing a "boring" existing RDBMS.
That sounds like an architecture issue. In 10 years I’ve used React for a wide variety of projects from digital publishing tools to realtime medical dashboards to WebRTC-based videoconferencing apps with 3D graphics. I’ve never seen a build require anything like that much horsepower or time.
Before modern web dev practices my team was notified a dev had started the wipe/reinstall OS process on a 1,000 bare metal lab desktops and servers due to a bug in their deployment script
From prior experience I knew only the OS partition had been nuked so far not old data. So my team collected the disks, closed a campus computer, connected disks via USB adapters, shorted the two pins on ATX power supplies to provide power to the disks and booted from the lab machines it was all connected to into a live USB Linux system where we ran recovery tools on ~600-700 SATA disks (some servers had been snapshotted to backup and didn’t need the effort)
That was the most interesting day in tech I’ve ever worked and I started my career designing add on boards for a company that sold to Nortel before they imploded; my output literally shipped late 90s-early 00s internet users packets around
Noodling if else and for loops day in and day around some biz context I don’t care about but some Harvard grad has seed money to advertise is the lamest; the 2010s, an entire decade if my career and since, has been really boring.
There was no 'boring tech revolution'. Instead we got 10 years of NodeJS and React monocultures. We got 'let's build everything with Javascript' as the replacement for polygot microservices. We got 'everything must scale horizontally' despite computer hardware improving linearly.
The fact is that people are tired of meme driven architecture. I don't care that conferences and blogs gave you this great architecture idea. I've tried it before and it sucked. Most of my career has been spent arguing against people trying to expand the amount of work we need to do to accomplish business goals.
I know it's fun to try new languages and design concepts. I did it at the beginning of my career. Everyone should do it. But being a senior engineer is not your chance to try out your pet ideas. It's time to build things efficiently and economically.
Foamed glass gravel was invented in the early 20th century, by the Soviets no less, and started being used more in the 80s. It is a "boring" technology. (Source: https://www.glavel.com/foam-glass-aggregate-guide/)
Also it was used for a temporary repair to get the road open again while a permanant repair was made using more conventional roadbuilding.
If you know something is a temporary repair and time is the most important consideration, you can take risks or shortcuts (crushed stone wasn't available) because you know it's not a permanent fix.
>>> Wouldn’t folks feel better making smart, reasonable, and incremental improvements? Consider cases like introducing Kotlin to gradually level-up a Java shop.
while I could agree on the "principles", specifically for this example I still have scars.
Too much costs, no much gain, and you end up with a single project (the first and last one) that no one want to touch and that will be the first to be "engineered back" to java - years later and with a lot of loss
I have seen this pattern many times. In some cases, we still have the "innovative" project, but it's now well behind the times, because no one wants to touch all the "innovative" (but poorly understood) code.
There is more than one cause, but an "innovative" project in 2010 might now just look like a trap with ancient technology. They often do not age well. So, if you aren't prepared to fail fast and rewrite them a few years later -- and many orgs are not -- this can be a problematic path.
"Mainstream" solutions may also be traps, but they are traps you can hire people to maintain or upgrade.
I think you can survive adopting, say, an unpopular language if you are willing to commit and hire-to-train for it, but it takes some focus and commitment, which can be difficult to get executive backing for in many shops. But one-off experiments with the tech stack can be risky unless you can really afford to rewrite failures promptly. FANGs can do this, of course, as can many Fortune 500 companies, but the majority of IT shops probably cannot.
I'm dealing with related issues at work right. Leadership is beating us over the head with the "innovation" hammer, without any consideration why and where they want to innovate. This mandate is a recipe for disaster in the hands of inexperienced tech-leads.
For example, there was an initiative to move from Talend to Azure Data Factory. Devs had to upskill, and it took them several months to deliver something that fails intermittently (with a huge cost behind it), and noone knows how to fix it.
I rewrote the pipeline in 2 hours (as simple Windows Service that parses a file and writes data to a DB), and polished it in around a day or so. Added some informative and error notifications, and we immediately saw benefits.
Innovation is fun, but some things just don't really need much of it. We've known how to do stuff like ETL for decades. We really don't need cloud-hosted solutions behind client secrets and gated services to load data into a DB.
Ironically, my boring solution seemed more "innovative" because users can now get customised notifications in different Teams Channels.
"Boring"/"exciting" tech isn't stifling or improving anything. These are orthoganal issues. Innovation can emerge from boring tech.
I'm a fan of the innovation token idea. You have n (where n is based on your team size) innovation tokens to make use of. They can be applied to your product, the technology used to build the product, or the infrastructure supporting the product.
Why is there a limit? Because budgets are limited, and products need to be completed.
I totally agree. I felt like the author understood this but wrote in a style to be provocative. I didn't catch much in the article that was actually disagreeing with rolling out new technologies gradually.
For example, something like `What about a PostgreSQL operation rewriting SQL stored procedures in PL/Python?` is both provocative (there are good reasons not to thoughtlessly move all your stored procedures to PL/Python) but it's also absolutely a feature of Postgres a company should investigate and understand.
And unless the project is something that nobody’s ever succeeded at in the past due to technical limitations, businesses tend to survive and thrive if they spend their innovation tokens on product instead of tech/infrastructure.
No, but it has VirtualThreads and while they are not the same it gives you similar performance benefits without having to deal with "async-y"/callback stuff
But it seems that progress requires innovation, and some innovations will fail while others will succeed, driving the "evolution" of technology a la survival of the fittest. Ideally anyways, as just with real evolution "fittest" doesn't always line up with our human perception of "best".
Progress requires innovation but it doesn't necessarily require your innovation. Progress happens when an innovation spreads. By the time it's spread across half the landscape it doesn't look like innovation any more, it's just how things are done. But it's still progress when it gets from 80% to 90%.
> Besides. Let’s not take the fun out of everything.
there's nuance in everything. But this line is what gets me about this article. Let's not prioritize the "fun" of devs for unnecessary toil of ops/SRE.
> Wouldn’t folks feel better making smart, reasonable, and incremental improvements? Consider cases like introducing Kotlin to gradually level-up a Java shop.
I'm mostly a Java guy (with occasional dabbing in Python/Rust or some web-y stuff) and recently had to quickly jump into Kotlin codebase and I find it utterly clusterfuck-y... I may felt awesome in Java8 days ages ago but nowadays with nice, steady Java development I don't see much need or appeal of using Kotlin...
> Namely, that an all-new construction material called Foamed Glass Gravel was used as infill during repair work. That is to say that the professionals in charge of rebuilding found a better way to do things than they’ve always been done. Moreover, those self-same professionals intentionally circumvented the slow supply chain to use the new-and-better thing.
This happens all the time in contemporary software.
But in the case of software, the scenario would be different: someone wants Foamed Glass Gravel on their resume, or as an accomplishment for their promo bid. So they do the free trial, and dump proprietary information into a Foamed Glass Gravel SaaS, and deploy a half-baked learning project. Then (most importantly) they hop jobs before the problems are obvious to everyone.
One difference is that, in the case of civil engineering, stakeholders care about maintenance problems and deaths, and the responsible engineers will be hunted down, to be sued and/or jailed. So, if a real engineer chose to sign off on something, it's probably legitimate and aligned.
The problem I have with the argument is that "improvement" needs to be something objective and measurable. "I'm throwing away old code because eww" isn't improvement. The two examples cited are very telling:
> Consider cases like introducing Kotlin to gradually level-up a Java shop.
But why? Introducing a second language to do pretty much the same thing is a giant leap in complexity and it's not obvious we'd get something real in return.
> What about a PostgreSQL operation rewriting SQL stored procedures in PL/Python?
Yet again, why? SQL is popular and very well understood, the alternative solution would be less portable and a rewrite would introduce unnecessary risk.
I was let's rewrite this app guy once. I rewrote the whole app and realized that main issues were documentation and lack of understanding by anyone within the business how the system actually works.
The new app is better, but if a new dev looked at the code base they would suggest a rewrite. I would want to do it too, but I just don't feel like joining that rodeo at the moment.
Throwing away old code and rewriting it in a sexy, new language also takes time away from projects that are actually meaningfully innovative: ie projects that help customers do more, or be more efficient
Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive.
Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features far more quickly. The only argument to keep with Java is that Java actually seems to be chasing after some of the gains Kotlin made.
> Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive.
[citation_needed]
> Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features
Java was stagnating on Android because Google was (and is) lagging with implementing newer features. Android 12 only got support for Java 11 ffs...
Interestingly enough with Project Mainline it will be possible to support newer Java versions in Android…
Strongly agree with this. Software Engineering needs something equivalent to evidence-based-medicine. (I think it exists, but isn't as widespread as it should be.)
Business needs that. Everyone jumped on the data-driven train (how rigorous was the information that lead them to do that? LOL) but it’s top-to-bottom bullshit. We have almost no clue how to measure management efficacy, for instance, and the methods we do have are too fiddly and require large sample sizes in just the right circumstances, so nobody but academics even try. It’s like that for almost everything. You look at the data gathering behind and analysis methods for the median strategy PowerPoint and it’s just gibberish, completely useless nonsense, and it doesn’t exactly take a trained & practicing scientist to tell, but everyone who can spot these things and is on the management track knows they’re not supposed to point that out. It’s all a big, weird game of pretend.
I don't agree at all. This is the McNamara fallacy applied to software. You don't have to measure management efficacy. When you call for rewriting project X in technology Y, this is, at a first approximation, just saying: What reasons do we have for thinking this will make a difference? What evidence exists to support such contentions?
You don't need to be able to perfectly measure things to have evidence. Evidence might be "We used Y in this other project because <it was good in some way>, and the engineers seem to be able to make changes faster: here's our data." Or "Technology Y is better at <some feature> because it <has more mature libraries, or a better approach to concurrency, or whatever>, so we think it will benefit us."
You don't have to be able to measure everything perfectly to make better decisions.
I agree! The current approach needs “science-based management” because that’s what it’s play-acting at—that’s what it would take to do the thing they’re claiming to do.
I think it’d be much better to admit that’s far too expensive and/or nearly impossible, plus probably not something most executives are interested in doing anyway, and back off the whole hyper-“legibility” (bad-)data-based-everything notion. It’s an expensive drag mostly delivering bullshit.
You're responding to a different end of the scale. Lots of shops are doing nothing, and that is not the right answer either. You can evaluate the data that exists and do a better job than they are doing.
Dude took an isolated instance where a well-tested new material engineering technique was used to fix a bridge and actually made an argument against boring technology. Amazing.
I wholeheartedly disagree with the sentiment. However, I will point out that not all tech is built for all purposes.
Just like we wouldn’t praise I-95 being rebuilt with silly putty just because the engineers enjoyed working with silly putty. They used a well-designed solution for a fitting problem.
So too do we need to consider that boring technology is usually the RIGHT choice. But in instances where it’s not, or where it doesn’t matter: knock yourself out! Have fun!
Hot take, but ime, a lot of developers who are hyper-luddites tend to not be good developers or developers who didn't/don't want to try to upskill.
This doesn't mean that you always need to use the newest and flashiest tool (eg. Bash+Awk preprocessing can still be faster than using multiple different packages), but you should still be aware and understand how to make those tradeoffs.
You choose your stack based on your problem statement, and as a business that requires taking both Engineering and Business considerations into account.
I would agree and expand on this and say such hyper-luddites tend to make picking up new technology a self-fulfilling bad idea. Even if you can present a fantastic business case for something they don't want to learn new things so if you do introduce it they will refuse to learn and progress will suffer as a result.
The thing I find most frustrating about “The Boring Revolution” is that it feels stuck in the particular year of 2015. Like, React has been out for 12 years. React is older now than Ruby on Rails was when the Boring essay came out. And yet I still hear people talk about React as this “shiny trendy thing”, even though it’s a mature technology with huge adoption, mountains of examples and documentation, and millions of developers with years of experience building in it.
If the essay had come out in 2008, Ruby on Rails would’ve been the “exciting” thing it was calling out. But instead, Ruby on Rails is generally considered in the “boring” camp, while things that came out closer to the essay’s publication like React are in a state of “Permanent Shiny”.
All of which blinds people to the fact that the web space has in fact settled down years ago and is not in the state of immense flux that actually was happening in 2015.
React to me will always feel like Java - a big solution by a big company for solving big company problems. When it is forced on small problems in small companies it creates unhappiness, yet, choosing something else feels like the "no one ever got fired for choosing IBM / Microsoft" dilemma.
React isn't big, it's about as small as a "framework" gets. The problem most people face is actually that the simplicity gives the developer unlimited freedom to craft whatever complex monstrosity they desire.
You haven't used vue 2 or svelte then. Modern React is big and opinionated (just like Angular). When people talk about react they are not just talking about a state management library anymore
Vue and Svelte are just as complex as React, I'd argue Vue often ends up being even more complex than react even though the barrier to entry is a bit lower for novices. If you disagree, I encourage you to link to a mature project on github built with svelte or vue that you regard as an example of simplicity.
The problem is by the time it does everything you need it to do, it's a fat turd again.
Your point is like saying C is a lightweight language. It sure is, until you have layered everything else you need on top of it.
That's exactly what I said. React is so simple and flexibile that it leaves a lot of room for developers to shoot themselves in the foot. The C analogy is spot on.
But it is though.
Saying react is complex is much like saying C is complex because of OpenGL or SDL.
React isn't the ecosystem anymore than C is.
There are plenty of "newer" technologies that closely mimic more "boring" tech too. For example, Svelte feels a lot like writing vanilla HTML and JS, Supabase is all built entirely on PostGRES instead of a shiny, noSQL database.
To reduce "the boring revolution" to a React aversion is a bit dismissive.
"Boring" is malleable. If your team is full of React experts, React is boring.
If your team is full of backend-oriented engineers who rarely deal with the frontend, React is much less boring.
"Boring" is also not binary; it is continuous. The mix of technologies in your stack culminate in some arbitrary measure of boringness. This measure can also be thought of as the degree to which teams choose cutting/bleeding edge technologies. If the mix is mostly cutting/bleeding edge, it's very likely that production support is not boring, and problems operating the stack in production are not boring.
Choosing boring technology is also not a panacea that solves every team's problems. Although doing so likely mitigates them.
100%
The biggest change in the last few years has been a shift from Webpack to Vite, which, IMO, is a breath of fresh air.
I've been using preact and I think it fills the bill of "boring" (the "good" boring) a lot better [1].
--
1: https://preactjs.com/blog/preact-x
I'm not really sure how you expected the mantra of use mature technologies that are stable, mostly unchanging, and have staying power could have turned out any other way. React Hooks which required a partial rewrite for every code base happened in React 16-17 which was in 2020. This is neither a boring or stable technology to build a business on. This doesn't mean it's bad but it doesn't survive the "I can pick the code up after a few years and get it up to date with minimal effort" test.
Write boring code is about going down paths that are well troddened enough that they paved a sidewalk which isn't going anywhere any time soon. Most of the frontend world can't even conceive of an LTS release right now.
I genuinely don't understand the author, choosing boring technology is about making choices so that that platform on which you stand is rock-solid. It's easier to exercise fun, creativity, and new ideas on such a platform because there aren't any sharp edges and you can start pushing a technology. The examples with introducing Kotlin or Python/PL seemingly aren't motivated by anything other than "they're new." What problem are they solving and do you have that problem?
> React Hooks which required a partial rewrite for every code base happened in React 16-17 which was in 2020
Except it was not required. Class components still work exactly as they did back then.
A problem might be major libraries moving on to Hooks-based interfaces
The same reasoning applies. Don't upgrade if you don't need the new features.
I don't know in what company you work at. But you can't have outdated libraries in production forever. Vulnerabilities happen. Stable does not equate outdated. Look at .Net. You can pick a codebase from 2014 and make your way around easily. It is like home. Similarly, your 2014 dev could jump into a time machine into 2024 and work with .Net Core easily. Also, 2014 codebase can keep getting the latest security patches without having to rewrite the codebase.
That's not the case with React or most of the js frameworks
> Look at .Net.
.net??? I worked with .net for about 10 years and over multiple versions of .net and .net core, the amount of time we spent facilitating upgrades was much more than I ever spent on upgrading a react app. In fact, at my last .net job I was hired specifically to transition the company's platform from .net to .net core. There was so much work involved that they literally created a role for it.
If your answer to how to make it stable is never update (including your dependencies) then you're not working on a stable technology.
Stable is being able to set up unattended upgrades on Ubuntu LTS fearlessly. When was the last time you worried about your kernel update?
> If your answer to how to make it stable is never update then you're not working on a stable technology.
I didn't say "never update", I said that if you don't need the new features then don't upgrade. If you do need the new features then I don't understand what the problem is.
> Stable is being able to set up unattended upgrades on Ubuntu fearlessly.
lol what? I've never had a system survive an Ubuntu upgrade without breaking something.
Point is many of these libraries don't just let you get latest without rewriting some of your code. Multiple that by 10-20 and you are in for a real treat.
> Point is many of these libraries don't just let you get latest without rewriting some of your code.
True of every software platform in existence.
On the scale of upgrade complexity, react is a walk in the park compared to e.g. everything in the android and ios world, or e.g. any application written for a desktop platform. Ever tried upgrading a C++ app? It's a nightmare beyond anything I've ever faced in my career.
I've never worked with Rust in a professional environment, but I've been a big fan of it for my personal projects for some years now, however, the introduction of async was a massive disruption to the entire ecosystem.
In my opinion, complaining about JS complexity in particular reflects ignorance of the wider software world.
Well yeah but Rust isn't a boring technology and C++ has its own reasons for being difficult. The goto examples of boring are C (and Objective-C), Java, Perl 5, PHP, Vanilla JS (the browser itself is remarkably stable), Rails, Django. Just a who's who of ecosystems people don't want to program in.
Perl code doesn't work today just as well as it didn't work 20 years ago.
Yep patching Ubuntu is so stable it's fully automatic and upgrading to the latest Ubuntu is 1-2 days work. Getting to the latest on our front end is a project.
You absolutely can/should/must use more exciting things if they are relevant to whatever unique problem you're trying to solve.
But everything else possible in your stack (particularly foundational elements) should be as boring as possible - i.e. unless you are specifically innovating in the area of RDBMS systems, you should be choosing a "boring" existing RDBMS.
React is not boring. We have to use a 64 gig machine to build one of our React things and it takes 45 minutes to do so.
I'm literally on a meeting now trying to work out how to make it boring again.
That sounds like an architecture issue. In 10 years I’ve used React for a wide variety of projects from digital publishing tools to realtime medical dashboards to WebRTC-based videoconferencing apps with 3D graphics. I’ve never seen a build require anything like that much horsepower or time.
Ah yes but you likely aren’t at the mercy of the lowest bidders!
That’s the definition of boring in tech.
Before modern web dev practices my team was notified a dev had started the wipe/reinstall OS process on a 1,000 bare metal lab desktops and servers due to a bug in their deployment script
From prior experience I knew only the OS partition had been nuked so far not old data. So my team collected the disks, closed a campus computer, connected disks via USB adapters, shorted the two pins on ATX power supplies to provide power to the disks and booted from the lab machines it was all connected to into a live USB Linux system where we ran recovery tools on ~600-700 SATA disks (some servers had been snapshotted to backup and didn’t need the effort)
That was the most interesting day in tech I’ve ever worked and I started my career designing add on boards for a company that sold to Nortel before they imploded; my output literally shipped late 90s-early 00s internet users packets around
Noodling if else and for loops day in and day around some biz context I don’t care about but some Harvard grad has seed money to advertise is the lamest; the 2010s, an entire decade if my career and since, has been really boring.
There was no 'boring tech revolution'. Instead we got 10 years of NodeJS and React monocultures. We got 'let's build everything with Javascript' as the replacement for polygot microservices. We got 'everything must scale horizontally' despite computer hardware improving linearly.
The fact is that people are tired of meme driven architecture. I don't care that conferences and blogs gave you this great architecture idea. I've tried it before and it sucked. Most of my career has been spent arguing against people trying to expand the amount of work we need to do to accomplish business goals.
I know it's fun to try new languages and design concepts. I did it at the beginning of my career. Everyone should do it. But being a senior engineer is not your chance to try out your pet ideas. It's time to build things efficiently and economically.
Foamed glass gravel was invented in the early 20th century, by the Soviets no less, and started being used more in the 80s. It is a "boring" technology. (Source: https://www.glavel.com/foam-glass-aggregate-guide/)
Also it was used for a temporary repair to get the road open again while a permanant repair was made using more conventional roadbuilding.
If you know something is a temporary repair and time is the most important consideration, you can take risks or shortcuts (crushed stone wasn't available) because you know it's not a permanent fix.
Foamed glass would be a really neat technology for use on the moon.
>>> Wouldn’t folks feel better making smart, reasonable, and incremental improvements? Consider cases like introducing Kotlin to gradually level-up a Java shop.
while I could agree on the "principles", specifically for this example I still have scars. Too much costs, no much gain, and you end up with a single project (the first and last one) that no one want to touch and that will be the first to be "engineered back" to java - years later and with a lot of loss
I have seen this pattern many times. In some cases, we still have the "innovative" project, but it's now well behind the times, because no one wants to touch all the "innovative" (but poorly understood) code.
There is more than one cause, but an "innovative" project in 2010 might now just look like a trap with ancient technology. They often do not age well. So, if you aren't prepared to fail fast and rewrite them a few years later -- and many orgs are not -- this can be a problematic path.
"Mainstream" solutions may also be traps, but they are traps you can hire people to maintain or upgrade.
I think you can survive adopting, say, an unpopular language if you are willing to commit and hire-to-train for it, but it takes some focus and commitment, which can be difficult to get executive backing for in many shops. But one-off experiments with the tech stack can be risky unless you can really afford to rewrite failures promptly. FANGs can do this, of course, as can many Fortune 500 companies, but the majority of IT shops probably cannot.
I'm dealing with related issues at work right. Leadership is beating us over the head with the "innovation" hammer, without any consideration why and where they want to innovate. This mandate is a recipe for disaster in the hands of inexperienced tech-leads.
For example, there was an initiative to move from Talend to Azure Data Factory. Devs had to upskill, and it took them several months to deliver something that fails intermittently (with a huge cost behind it), and noone knows how to fix it.
I rewrote the pipeline in 2 hours (as simple Windows Service that parses a file and writes data to a DB), and polished it in around a day or so. Added some informative and error notifications, and we immediately saw benefits.
Innovation is fun, but some things just don't really need much of it. We've known how to do stuff like ETL for decades. We really don't need cloud-hosted solutions behind client secrets and gated services to load data into a DB.
Ironically, my boring solution seemed more "innovative" because users can now get customised notifications in different Teams Channels.
"Boring"/"exciting" tech isn't stifling or improving anything. These are orthoganal issues. Innovation can emerge from boring tech.
I'm a fan of the innovation token idea. You have n (where n is based on your team size) innovation tokens to make use of. They can be applied to your product, the technology used to build the product, or the infrastructure supporting the product.
Why is there a limit? Because budgets are limited, and products need to be completed.
I totally agree. I felt like the author understood this but wrote in a style to be provocative. I didn't catch much in the article that was actually disagreeing with rolling out new technologies gradually.
For example, something like `What about a PostgreSQL operation rewriting SQL stored procedures in PL/Python?` is both provocative (there are good reasons not to thoughtlessly move all your stored procedures to PL/Python) but it's also absolutely a feature of Postgres a company should investigate and understand.
Yup.
And unless the project is something that nobody’s ever succeeded at in the past due to technical limitations, businesses tend to survive and thrive if they spend their innovation tokens on product instead of tech/infrastructure.
Author seems to conflate innovation with progress.
Just because something is innovative (like in his example introducing kotlin when everyone else is using Java) doesn’t mean it will lead to progress.
Introducing kotlin during the Java 8 era was innovative. In 2024 with Java 23 out you aren't gaining anywhere near as much.
Does Java 23 have coroutines?
No, but it has VirtualThreads and while they are not the same it gives you similar performance benefits without having to deal with "async-y"/callback stuff
But it seems that progress requires innovation, and some innovations will fail while others will succeed, driving the "evolution" of technology a la survival of the fittest. Ideally anyways, as just with real evolution "fittest" doesn't always line up with our human perception of "best".
Progress requires innovation but it doesn't necessarily require your innovation. Progress happens when an innovation spreads. By the time it's spread across half the landscape it doesn't look like innovation any more, it's just how things are done. But it's still progress when it gets from 80% to 90%.
> Besides. Let’s not take the fun out of everything.
there's nuance in everything. But this line is what gets me about this article. Let's not prioritize the "fun" of devs for unnecessary toil of ops/SRE.
> Wouldn’t folks feel better making smart, reasonable, and incremental improvements? Consider cases like introducing Kotlin to gradually level-up a Java shop.
I'm mostly a Java guy (with occasional dabbing in Python/Rust or some web-y stuff) and recently had to quickly jump into Kotlin codebase and I find it utterly clusterfuck-y... I may felt awesome in Java8 days ages ago but nowadays with nice, steady Java development I don't see much need or appeal of using Kotlin...
> Namely, that an all-new construction material called Foamed Glass Gravel was used as infill during repair work. That is to say that the professionals in charge of rebuilding found a better way to do things than they’ve always been done. Moreover, those self-same professionals intentionally circumvented the slow supply chain to use the new-and-better thing.
This happens all the time in contemporary software.
But in the case of software, the scenario would be different: someone wants Foamed Glass Gravel on their resume, or as an accomplishment for their promo bid. So they do the free trial, and dump proprietary information into a Foamed Glass Gravel SaaS, and deploy a half-baked learning project. Then (most importantly) they hop jobs before the problems are obvious to everyone.
One difference is that, in the case of civil engineering, stakeholders care about maintenance problems and deaths, and the responsible engineers will be hunted down, to be sued and/or jailed. So, if a real engineer chose to sign off on something, it's probably legitimate and aligned.
This author tries to make a claim but the argument involves too many things at once and isn't quite precise enough to make an impact statement.
The problem I have with the argument is that "improvement" needs to be something objective and measurable. "I'm throwing away old code because eww" isn't improvement. The two examples cited are very telling:
> Consider cases like introducing Kotlin to gradually level-up a Java shop.
But why? Introducing a second language to do pretty much the same thing is a giant leap in complexity and it's not obvious we'd get something real in return.
> What about a PostgreSQL operation rewriting SQL stored procedures in PL/Python?
Yet again, why? SQL is popular and very well understood, the alternative solution would be less portable and a rewrite would introduce unnecessary risk.
I was let's rewrite this app guy once. I rewrote the whole app and realized that main issues were documentation and lack of understanding by anyone within the business how the system actually works.
The new app is better, but if a new dev looked at the code base they would suggest a rewrite. I would want to do it too, but I just don't feel like joining that rodeo at the moment.
This cycle will repeat till the end of time.
Throwing away old code and rewriting it in a sexy, new language also takes time away from projects that are actually meaningfully innovative: ie projects that help customers do more, or be more efficient
Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive.
Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features far more quickly. The only argument to keep with Java is that Java actually seems to be chasing after some of the gains Kotlin made.
> Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive.
[citation_needed]
> Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features
Java was stagnating on Android because Google was (and is) lagging with implementing newer features. Android 12 only got support for Java 11 ffs...
Interestingly enough with Project Mainline it will be possible to support newer Java versions in Android…
Strongly agree with this. Software Engineering needs something equivalent to evidence-based-medicine. (I think it exists, but isn't as widespread as it should be.)
Business needs that. Everyone jumped on the data-driven train (how rigorous was the information that lead them to do that? LOL) but it’s top-to-bottom bullshit. We have almost no clue how to measure management efficacy, for instance, and the methods we do have are too fiddly and require large sample sizes in just the right circumstances, so nobody but academics even try. It’s like that for almost everything. You look at the data gathering behind and analysis methods for the median strategy PowerPoint and it’s just gibberish, completely useless nonsense, and it doesn’t exactly take a trained & practicing scientist to tell, but everyone who can spot these things and is on the management track knows they’re not supposed to point that out. It’s all a big, weird game of pretend.
I don't agree at all. This is the McNamara fallacy applied to software. You don't have to measure management efficacy. When you call for rewriting project X in technology Y, this is, at a first approximation, just saying: What reasons do we have for thinking this will make a difference? What evidence exists to support such contentions?
You don't need to be able to perfectly measure things to have evidence. Evidence might be "We used Y in this other project because <it was good in some way>, and the engineers seem to be able to make changes faster: here's our data." Or "Technology Y is better at <some feature> because it <has more mature libraries, or a better approach to concurrency, or whatever>, so we think it will benefit us."
You don't have to be able to measure everything perfectly to make better decisions.
I agree! The current approach needs “science-based management” because that’s what it’s play-acting at—that’s what it would take to do the thing they’re claiming to do.
I think it’d be much better to admit that’s far too expensive and/or nearly impossible, plus probably not something most executives are interested in doing anyway, and back off the whole hyper-“legibility” (bad-)data-based-everything notion. It’s an expensive drag mostly delivering bullshit.
You're responding to a different end of the scale. Lots of shops are doing nothing, and that is not the right answer either. You can evaluate the data that exists and do a better job than they are doing.
Dude took an isolated instance where a well-tested new material engineering technique was used to fix a bridge and actually made an argument against boring technology. Amazing.
I wholeheartedly disagree with the sentiment. However, I will point out that not all tech is built for all purposes.
Just like we wouldn’t praise I-95 being rebuilt with silly putty just because the engineers enjoyed working with silly putty. They used a well-designed solution for a fitting problem.
So too do we need to consider that boring technology is usually the RIGHT choice. But in instances where it’s not, or where it doesn’t matter: knock yourself out! Have fun!
BTW such a beautiful font. Anything you write with et book will look classy :-)
--
https://edwardtufte.github.io/et-book/
> all-new construction material
Foam glass gravel? If this was an analogous computer software article, it would read
""" ... and in 2023, the team shipped a frontend in record speed using an all-new programming language "JavaScript"... """
Maybe foam glass gravel is new on the scale of construction materials, sure? But it's been used in road construction since the 1990s.
So this article reads a bit... strange to me.
Other poster pointed out that the base foam glass tech was invented in the 1930s
So actually it would be more like
""" ...and in 2096, the team shipped a frontend using an all-new JavaScript framework called Foo, first used in Norway in the late 2050s..."""
Hot take, but ime, a lot of developers who are hyper-luddites tend to not be good developers or developers who didn't/don't want to try to upskill.
This doesn't mean that you always need to use the newest and flashiest tool (eg. Bash+Awk preprocessing can still be faster than using multiple different packages), but you should still be aware and understand how to make those tradeoffs.
You choose your stack based on your problem statement, and as a business that requires taking both Engineering and Business considerations into account.
I think there are two poles that devs tend to cluster around.
On the luddite end, you have a lot of developers who are uncreative and vastly prefer reading code to writing it.
On the other end, you have rewriters who can ONLY read code they've written themselves.
You actually need both types to have a good team.
I would agree and expand on this and say such hyper-luddites tend to make picking up new technology a self-fulfilling bad idea. Even if you can present a fantastic business case for something they don't want to learn new things so if you do introduce it they will refuse to learn and progress will suffer as a result.
[dead]