I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and MongoDB. That probably cost the company X million dollars. Etsy could still be recovering from that.<p>The industry constantly mints senior engineers who have been bitten by complexity, but doesn't want to hire them, or listen to them. More often than not senior engineers pretend to be excited about complecting the tech stack, because hey, it pads their resume with the latest buzzwords and they've given up trying to fight against it anyway.<p>The last line of defense against a rogue engineering team is managers who have studied this stuff. How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it?<p>Anyway, this is a cool website, and it'll be useful to point people to it in the future, so thanks for that.
The problem with the non-boring technology club is that programmers see what problem FAANG companies are solving and wanting to be on the edge on new technology too. But they don‘t have the same problems. Another problem is they want to show what they can do. If they tell in an interview they are working with rails/django and a postgresql database they fear they look incompetent using those old technologies. So they try to convince their companies their products need to be rewritten in mongodb, react with graphql in a micro service stack and many more state of the art technologies.<p>And in the end many developer years are wasted just rewriting a working an existing software in a new stack they are not yet comfortable with and the new product is much less stable than the old one.<p>I love basecamp for their hotwired stack and showing that you can make the great software with old boring technologies and just a little bit of javascript magic pixie dust.
The way I see it is that one should master their stack. If you work over and over again with the same stack you will know it well. You will be able to move mountains with it. But it takes years to arrive to that. It takes implementing multiple projects the same way over and over again.<p>You need the wherewithal to stick with your stack and not get lured away. Maybe this is what boring means. Maybe boring is different to different engineers based on their background.<p>Sometimes you cannot select the stack cause there might be more senior engineers at a company and they have more sway. This is fine as long as the engineers picking the stack have picked a stack they have mastered and it is boring to them. As a regular engineer in their team I would hope to rely on their expertise and would hope to learn from them.<p>I remember at one job a rogue engineer picked a boring backend that would have been fine. But they fell behind because the other engineers knew their boring stack a lot better. Ultimately the rogue engineer had to switch to the other boring stack. The rogue engineer just was not fast enough to master it and implement the features required to keep pace with the demands of management. These demands were trace centralized logging, security, and of course features. So while they were still learning the ropes, we were moving on to even more advanced security, logging, and feature requirements. They just couldn't keep up.
The aviation industry has an expression: "there are old pilots and there are bold pilots but there are no old bold pilots". Young, inexperienced pilots often take unnecessary risks and occasionally learn important lessons - sometimes terrifying lessons. Those lessons lead to a more cautious approach to flying as they grow older. It seems to me that boring tech is equivalent to cautious flying. Experience matters. Maybe its time to co-opt that expression into the developer world - "there are old coders and there are bold coders but there are no old bold coders". Ageism is a problem in the tech world. Experience will almost always consider (maybe even prefer) boring tech - generally for good reasons. Perhaps its time to value experience a bit more than we have.
Generalizations like “choose boring technology” are just unhelpful slogans.<p>Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan.<p>There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies.<p>When someone comes at your approach wielding a slogan, be skeptical.
Reading this sounds like dejavu.<p>A company I’ve worked with also had a PHP monolith which was supposed to be split up into microservices to improve maintainability. The choice of language was free, and the first ones were, kid you not, written in PHP using some alpha-quality library which was supposed to make PHP asynchronous, to improve “scalability”. Comically, this stack was used in an image-serving service which had to perform blocking image resizing using ImageMagick. Due to this misunderstanding of the technology, the only way to keep it afloat was to run 90 containers in a home-managed Kubernetes cluster just to keep requests from queuing up. Another comic misunderstanding of this paradigm was when I traced down a bug where the process seemed to hang due to the fact that the developer had intentionally added a call to sleep in a loop. Coming from a Java/.Net background, they believed it would cause the “current thread” to sleep in order to not hog resources. This was problematic since the application (like nodejs) was single-threaded.<p>I didn’t want to work with that stack, so when it was my turn to work on a new microservice, I chose Scala + MongoDB (same as Etsy) because I wanted to learn about functional programming. Ironically, the microservice was basically a “checkbox as a service”, but I and the tech lead on the team were too brainwashed/high on learning new things to realize the overcomplexity.<p>The entire thing was an expensive lesson that I and some others got to learn from. The ones who didn’t learn kept their microservices ideology and found other jobs.<p>Fast-forward and the entire thing was scrapped and rewritten as a Django + Postgres monolith. Not to say that it wasn’t costly to do a rewrite, but infinitely less costly than continuing down the microservices road. Long live boring technologies.
A lot of new technology eventually becomes boring technology, and this is because of adoption in companies exactly in the way the author is discouraging. When the new becomes boring, everyone gets to reap the benefits of the new tech.<p>The world of software rests on the hard work of others, whether it's open source maintainers spending their free time making libraries for peanuts, or it's people going through the pain of productionizing a new technology. Being in the boring technology club is in a sense also being in the freeloader club, never contributing back to the state of the art.<p>It's a good article. It makes us aware of the drive many have to use the new thing, and the negative consequences of following this drive blindly. But I'm also happy that people do it.
This stack can be radically simplified:<p>Apache: managing open connections. Memcache: holding stuff in memory. Postgresql: Save stuff to disk. Cron: Schedule things. Python: wire the above things together<p>... or a good reason the pick Go or Java
Urgh, this feels familiar. Last year I left a company that was just wrapping up a new tech product, everything was microservices and mongodb. Trying to get a simple answer out of the engineering team about something as trivial as “how can I get a list of customers who have purchased product X” was almost impossible.<p>They sure had fun building it though.
The title of this article, which makes rounds on HN, bothers me.<p>It's not about choosing a "boring" tech. It's about choosing <i>tools you understand well and a master of</i>.<p>You can be totally excited about e.g. TypeScript or Elixir, but as long as you have a solid experience of working with them, and a good understanding of their internals, they are safe bets.<p>Choosing a perfectly boring thing like Cobol is not going to help if you have no solid mainframe experience.
I can understand this from the perspective of a manager or company owner. "Happiness comes from shipping products" or "Choose boring technology" make a lot of sense if you are maximizing profit and don't need to work with the tech yourself.<p>If you are an engineer and you want to try a new technology, go for it. Even if it doesn't make sense. Learn new things, don't stick with the boring tech. Maximize your own happiness and your own knowledge, not the profit of your higher-ups.
The redis/memcache example doesn't make a lot of sense to me, unless the idea is that a separate memcache instance is deployed alongside each backend, while redis would have been a single instance.<p>I'm all for boring technology; reimplementing web protocols and semantics in JS is a disaster - and would probably have made a clearer case study than comparing to memory-first database caches.
I think that technology used needs to be chosen based on today's needs and not tomorrow's. Startups that decide to deploy 5 containers on kubernetes make me cry. The time and cost to operate and maintain this beast is beyond any estimate compared to even hosting each container on a seperate vm.
This read was very satisfying, thank you
I still think the Simplicity Chapter in the Google SRE book sums this up best<p><a href="https://sre.google/sre-book/simplicity/" rel="nofollow">https://sre.google/sre-book/simplicity/</a>
How do we make progress if everyone just chooses to use boring technology which is already established? There would be no Rust, no Ruby or other great pieces of technology as they cannot thrive without communities. Communities cannot thrive if everyone neglects everything that’s new and exciting.
This is one of those posts where you can really feel the value of senior engineering/previous experience.<p>I definitely have not approached choosing a new technology with the velocity vs. maintenance trade off, instead just choosing the technology best fit for the job at hand. But when looking at a system holistically, this may not be the best choice. It’ll be good to at least know to consider this in the future (although I’ll admittedly probably still bias towards “fun” technologies).
This essay from David Perell touches on a similar concept: <a href="https://perell.com/note/lateral-thinking-with-withered-ideas/" rel="nofollow">https://perell.com/note/lateral-thinking-with-withered-ideas...</a><p>> It led to the 20th century’s most successful game console: the Game Boy. One day, a gaming engineer named Gunpei Yokoi was commuting home on the train when he saw a man playing with an LCD calculator next to him. Unfortunately, Nintendo didn’t have the budget to push the technological frontier at the time, so they used old technology to innovate. So long as the gameplay was engaging, Yokoi believed that players didn’t care about technical details like colors or screen resolutions. Compared to its contemporaries, the Game Boy was durable and affordable, which removed barriers to entry for users and developers. People would play for hours because it used AA batteries that were cheap and easy to find. Today, the Game Boy has sold more than 118 million units.
Lots of people here are shitting on mongodb(maybe rightly so). But I think the biggest problem is that the developers making the decision on what kind of DB to use just do not understand these tools.
I always recommend reading Designing Data Intensive Applications as soon as you have an inkling that you will be asked to make such decisions in the near future.
I think what people sometimes fail to realize is that the software ecosystem has simply become more specialized. There is now a higher-bar due to the competition between entrenched technology companies with armies of engineers continuously optimizing everything. So, depending on the industry/domain - aside from a useful product you need to consider a lot more: apps that work across platforms, performance, security, compliance, SEO/marketing, analytics, speed of iteration/delivery, infrastructure reliability, etc. All these contribute requirements that add complication.<p>So if you want a company that can do all that you are going to need specialists which typically come wielding specialized technologies. You can probably get away with generalists wielding 'boring' technologies for some period of time combined with SaaS solutions but it's hard to avoid the fast-moving increasingly specialized ecosystem forever.
Having shiny cool tech to solve problems isn't all too different than having 1. a hip office to work at, WeWork-style 2. wearing the latest fashion or latest cool hoodie if you're in SV 3. latest mechanical keyboard design ... the list goes on and on. It makes everything easier, 1. you can hire easier because the hip engineers see new shiny thing and would love to work on it most likely even if there is a slight pay cut or even if the product doesn't appeal to them as much as working at another company, senior engineers tolerate shiny new tech because a. they know they were once awestruck by other technologies when they first came out b. there is always a non-zero probability the shiny new thing is actually fundamentally better not just a short lived fad.<p>It's not a great explanation because it's a human issue, which usually as its solution has a mixed bag of technical and emotional reasons.
This is why I prefer buying 15+ year old cars, you know everything that's wrong with them. OK, it just so happens that three cars I've owned has been over 15 years old when I bought them, but I haven't heard a good car analogy in a while.
Lots of good stuff in this article. The way I read this is that all technology choices boil down to business cases which attempt to predict costs and benefits. I think it is important to note that the pros and cons which get weighed up in such a situation will cut across all aspects of a project - not just hard aspects (eg. Functional needs, performance, complexity, technology maturity, etc) but also importantly soft aspects like compatibility of the technology with team culture, individual personalities, career objectives, etc. It’s a complex problem and assessing the value of each pro/con is mastery which I believe requires a
vast amount of knowledge and experience.
I agree with all the arguments in the post... but man, I am so unproductive in the mainstream languages (Java especially). It feels like running in sand once you've experienced the other side.
One thing missing from the essay:<p>If you hire people that are more interested in solving the problem, then they are the tech ... the problem goes away.<p>Using some 'fancy, risk new thing' has utterly no appeal to someone trying to do XYZ by a certain time with a certain quality.<p>This is one of the biggest dissonances between Eng. and many business roles.<p>I've personally gone through the 'perspective shift' over my career, and I don't want to look at my younger self as desperately naive, but really it looks that way from a business perspective.<p>Even doing Engineering now, I generally could care less about the tech, and that makes you think very differently about it. I almost cringe the moment someone brings up something weird. The risk is of course being the 'crusty naysayer' but in most cases, it makes sense. New Tech is still in R&D, unless there is something very specifically and overwhelmingly advantageous to that tech with regards to your business, it's just a risk. To Zoom ... Mongo, Rust and Scala probably are not there yet in terms of the obvious advantages, whereas a new video codec might might meet the threshold of 'we have to look at this'.
I have dreadful stories about the amount of technical debt my team has faced because of one hedonist developer. He was good, but he had failed to understand the beauty of a boring stack. He kept reinventing the wheel, and over-engineering every part of the project.
Keeping this in mind, I only pick shiny new tech if it achieves a superficial task, is fast to implement, and can be replaced easily.
"Boring" in the sense used here really means something like "reliable" or "low-maintenance". Think of the old Maytag Repairman ads: he's just sitting there waiting for a call that never comes because Maytag washing machines are so reliable, get it?<p>Interestingly, this kind of boring can be measured. On the other hand, the kinds of things that one finds fun is idiosyncratic and subjective. I think it's an important distinction: we can argue about "boringness" with data, but a discussion of "exciting" software is much more like a discussion of personal tastes.<p>Take Elm for example, it's a highly reliable system for building front-end web apps, so in that sense it's very boring (in a good way!) but whether or not you find it exotic or exciting has a lot to do with your personal experience with Functional languages and such. To some people Elm seems like a toy, while to others it's a strange new world.
Technology is just a tool, or not ?<p>By a tool, i mean, we still use boring algorithms (which exist long before the tech is born to adapt it efficiently).<p>So, boring tech or not, it's not the point, as long as it serve your purpose.
There’s a lot of social status and perception-shaping tied up in who gets to do what innovation.<p>I’ve noticed that the very same ilk of leadership/managers who would balk at the complexity of adding a linter or json schema validation and cite “someday, that would be nice, but for now we’ve got to get quick wins and ship features” would not hesitate to let a golden-boy architect who’s also a drinking buddy add a CQRS microservice written in Go communicating in some hand-rolled bespoke protocol—-just because it wins some folks cool points.
Thank you for sharing and explaining this. As a former software engineer I finally understand the other side of the argument. More than just being told it's a "business decision".
As I commented on Quora [0] a while ago:<p>That is basically the inverse of Clarke’s First Law: Any sufficiently understood magic is indistinguishable from boring technology.<p>[0] <a href="https://www.quora.com/Are-Google-software-engineers-really-doing-anything-extraordinary-day-to-day-than-simply-coding-fixing-some-quite-trivial-software-stuff/answer/Robert-Rossney?comment_id=56389128&comment_type=2" rel="nofollow">https://www.quora.com/Are-Google-software-engineers-really-d...</a>
What a great post!<p>> I learned a lot. It kept me motivated through hard times with no customers, as I kept saying to myself if this won’t work, at least I’d learn something.<p>This is where I am at right now. I am trying to moonlight my own learning platform with two kids and a full time job, using a new-to-me technology is what keeps me going. It removes the stress of success because, no matter what, I succeed in some corny kind of way. Both myself and my existing employer get a better version of myself I’m the end.
> My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else.<p>>I don’t know if this makes sense for fashion or what have you, but I really think there is something to this.<p>Johny Bravo was conserving his brainpower all along !<p>I kind of like this idea, will probably try this, jeans + long and short sleeved versions.
Two observations:<p>- The slide with the jeep together with the "use boring technologies" slogan paints an interesting picture of the challenges of E-mobility in this century. There are going to be a lot of things no one expected.<p>- How would you call this style of presentations? Zen-like? One catchy thing per slide? I find it pretty well done, and when I compare it to my own "wall of text" slides, I am a bit jealous.
Hell yeah, I still love working on my 9 years old MySQL+PHP side-project. No build process, no issues with updating to latest package versions, it just works and you are not fighting with the language or tooling itself.<p>I did add meanwhile some extra parts on top to improve the development and releasing process, but those parts can be changed and removed at any point and the project would still work as expected.
> New tech typically has more known unknowns, and many more unknown unknowns. And this is really important.<p>Isn't this true in many facets of life? Like.... taking a new job... having your first kid... visiting a new city...<p>Are there processes for engaging in any new experience that enable you to know the outcome is going to be net positive before commencing?
I forget sometimes in interviews not everyone reads HN religiously. And I also forgot where I'd learned about "innovation tokens". Needless to say it would have helped to point interviewers to this full talk when explaining why we focused so hard on simplifying our technology stack.
By committing to an technology early you are limiting your options! You are limiting the possible ways problems can be solved. You are limiting the talent pool/hiring options.
I think there's an unfairness angle to it, if someone like the CTO makes the "boring" call. He then hacks maybe a few things here and there, but the one's to "sucker up" are the devs who have to program some "boring" shitty tech every day.
My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and loves the new stuff. But once he is out of the picture, we will be maintaining two highly redundant stacks both requiring deep technical knowledge to maintain effectively. I guess bailing is always an option, but I would prefer to be a force for good somehow. Any suggestions?
Really good presentation. Even in this form. These are the best arguments for choosing Boring Tech that I’ve seen yet.<p>Almost gave me a sinking feeling:<p>> If you behave that way you miss out on the part of the curve that we call “mastery.” That’s a state to the right on this curve, where there are still problems. Everything still sucks but it feels manageable.<p>> The grim paradox of this law of software is that you should probably be using the tool that you hate the most. You hate it because you know the most about it.