57 ms·

Choose Boring Technology (2015)

603 points by asyrafql 6y ago

nicois 6y ago
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. 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.
- the_gipsy 6y ago
  Especially when he said that some people did have to work on that setup to scale it up. Sounds like devops work, so the same would have happened with redis, right?
  - CamouflagedKiwi 6y ago
    He covers this - the operational setup & expertise to scale Memcached already existed because Etsy already used it elsewhere. It would have had to be built and learned (mostly) separately for Redis.
    - the_gipsy 6y ago
      I meant the part where he talks about maintenance later on.
      - ryanbrunner 6y ago
        Maintenance is also something that has to be learned (and "built up" in the sense that you're going to accumulate playbooks and processes over time). If a team already existed that knew the ins and outs of memcached, knew how to resolve any problems it encountered, already had appropriate monitoring / alarms / etc, that's a massive leg up over needing to do all that with a completely new technology.
fiftyacorn 6y ago
I still think the Simplicity Chapter in the Google SRE book sums this up best https://sre.google/sre-book/simplicity/ https://sre.google/sre-book/simplicity/
polote 6y ago
previous discussion (348 comments) https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246
- jsnell 6y ago
  Also: https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215
phendrenad2 6y ago
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. 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. 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? Anyway, this is a cool website, and it'll be useful to point people to it in the future, so thanks for that.
- Mikushi 6y ago
  > The last line of defense against a rogue engineering team is managers who have studied this stuff. If your engineering team is the one pushing in that direction I'd reckon the company was in a bad spot to begin with to have hired that team because it strongly indicates that the management layer (head of tech/CTO) has no technical clue. Hire strong Lead Developers with a proven track record of delivering value to companies they worked at and you'll be mostly fine. Also there's not much to study, in 99% of the cases in a web based startup if your stack deviates from a monolith with one of PHP/Ruby/Python/.NET/Go + Mysql/Postgres/MSSQL you're doing it wrong.
  - js4ever 6y ago
    What's wrong with Node.js? It's super mainstream now. We have it in production since years, I see a LOT of companies migrating from everything else to node since years and it's a growing trend from what I see at my level with startups and even enterprises
trestenhortz 6y ago
Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. 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. When someone comes at your approach wielding a slogan, be skeptical.
- krenel 6y ago
  > When someone comes at your approach wielding a slogan, be skeptical. I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things. Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"
  - trestenhortz 6y ago
    Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.
    - krenel 6y ago
      I would agree that we're talking about the same thing, really: > The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.
    - sverhagen 6y ago
      It may. But probably it doesn't. Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.
tpetry 6y ago
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. 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. 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.
- threeseed 6y ago
  Basecamp is a simple app though. Ridiculously simple. That app could have been written in the mid-1990s using WebObjects in just a few months. Technologies like MongoDB, React, GraphQL, Microservices etc exist because modern, real-world apps are generally far more advanced than just a glorified CRUD app. Consumers simply have higher expectations and more demands for what web apps should be able to do.
  - overkalix 6y ago
    > modern, real-world apps are generally far more advanced than just a glorified CRUD app. ... are they?
    - reasonabl_human 6y ago
      ...yes
  - ryanbrunner 6y ago
    While this is somewhat true and you can't solve everything with Rails + Postgres, you should ask yourself very, very hard about whether what you're building is in that category (and further, whether every part of what you're building falls into that category). Far, far too often I think a significant source of complexity is enthusiastically added by engineers themselves assuming that the problem they're solving is sufficiently complex that boring technologies just aren't up to the requirements of their project. My current gig is writing a very traditional Rails app (we hardly even dabble in Stimulus or Javascript all that much). Prior to that, I worked on a Javascript-backed fully reactive real-time app using the latest and greatest of technologies. My boring old Rails app, IMHO, has a much nicer user experience, far fewer quality issues, and is well loved by customers, where the bleeding edge Javascript app was constantly deried by customers for being difficult to use, buggy and unintuitive. You can go a long way with simple technologies if you design your experiences well.
the_gipsy 6y ago
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.
- jeromenerf 6y ago
  In my experience "boring" is less correlated to "shitty tech" than poor organization. Most dev work is "blue collar" work, following top down business decisions. The opportunities for devs to push impactful bottom up projects for a company business are rare at best. I have always preferred organizations where business problems-to-solve were pushed top-down rather than executive decisions. It encourages business understanding, initiatives and ownership.
  - phabora 6y ago
    Blue collar is not a synonym for subordinate.
- ryanbrunner 6y ago
  I don't think this has to be true. I've worked in many places (granted, smallish teams of less than 20 or so) where tech decisions were made collectively, without even that much input from the CTO. Choosing boring technology doesn't have to be a top down thing, although it probably needs to have some mechanism for aligning a whole team (since 10 different "boring technologies" are no longer boring and bring along all the problems of using shiny new toys).
- datavirtue 6y ago
  Dude, you can go home and play with any toy you want.
wrnr 6y ago
This stack can be radically simplified: Apache: managing open connections. Memcache: holding stuff in memory. Postgresql: Save stuff to disk. Cron: Schedule things. Python: wire the above things together ... or a good reason the pick Go or Java
- hnedeotes 6y ago
  Or better, Elixir + Postgresql
  - nhumrich 6y ago
    Not sure elixir qualifies as "old and boring tech"
    - yellowapple 6y ago
      Elixir, probably not. Erlang (and more broadly OTP), however, definitely qualifies IMO, at least depending on point of view. And given that Elixir is just an alternate language targeting OTP on Erlang's VM, there ain't much stopping folks from treating it as exactly that (and sticking with things like Yaws and Mnesia/CouchDB instead of the latest Phoenix hotness).
    - hnedeotes 6y ago
      (this got out of hand...) I understand what you're saying and think you're right, in terms of not having had the same time running in the wild to have the same knowledge base and ecosystem as other solutions. But looking at what it actually is, it's a layer over the much older underlying technology, which is Erlang, once you look at the frameworks used, they are basically implementations of things we consider old approaches, despite including new features. Some examples: - Phoenix - it's a MVC framework, it's not much different from any MVC framework except it doesn't have the "model". You can entirely use it in that "boring" CRUD app way and it will be a great choice. It's performant and has a templating system for HTML, a plug system that looks like middlewares. But if you need to use web sockets without ceremony or want to try something shiny like live views, you can as well. You're not forced to though and you don't need to use nodejs for your js either (as an example) - Ecto - It looks like an ORM but isn't an ORM, it's default choice for database is Postgresql. It's a library that mimics SQL itself (the helpers and the way you use it are as they would be used in SQL but designed to be chain able and sanitised), it also has easy ways of executing SQL while still sanitising it and also of writing raw SQL. So, pretty boring in all senses except the slight change in syntax to write the queries in elixir. This means for instance a distinct clause would be distinct(query, [table_mentioned_in_query], asc: table_mentioned_in_query.platform) This is not written as sql, but it maps to sql one to one. It uses schemas which are just that, schemas that map how values are dumped and cast from the DB, they're not models/objects, they're just data structures. But if you want to get fancy it also has embedded schemas if you want to use jsonb for instance, that allow you to use jsonb columns while still maintaining a "typed" schema from dump to read. What may look a bit alien is perhaps the access to OTP libraries that Erlang offers, the way the VM works and certain abilities that come from the way you will structure an app, but even those when we think about them, it's basically what any OS does, or the way kernels work. You have processes, they have identifiers, you can name them, you can run a lot of them concurrently, they can have separate lifecycle trees/dependencies, they have interfaces, you pass "messages" between them. Maybe what's "new" when you compare it to other languages is that this is not usually available to them but I would argue that most of our systems are implemented exactly in that way because it's the most reasonable outside very specific constraints/needs. When you use Elixir, Phoenix and Ecto you don't need to use these (or understand them deeply), usually the libraries take care of that for you. You can start as if you were writing a nodejs, rails, .net, python or whatever application. But then if you actually need you have a host of utilities and a runtime that I think is excellent for the kind of things most apps out there need, in a single runtime, and you can take it pretty far before you need to extend the stack and that has value in itself I think.
solanav 6y ago
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. 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.
- WJW 6y ago
  Boring technology also has the benefit of not waking you up in the middle of the night as often, because most of the weird bugs have been rooted out by other people. This can also be a downside of course, depending on how your particular org rewards "firefighters".
- serial_dev 6y ago
  Totally, one can understand both sides. In my opinion, it also works in the other direction, where the managers push things onto the developers. "Can we use this blockchain thing?", "we need to do AI", "we should use this cross platform mobile app tool I heard and read 3 minutes about".
- cjfd 6y ago
  Actually, also as an engineer much happiness comes from shipping products. Also, happiness comes from programming as opposed to configure and/or repearing a baroque tech stack with technologies that are not needed anyway but still break every other week. The latter thing comes with anger and the desire to scold (if not worse) the persons who needlessly brought in the complexity. If you want to learn new things there is your spare time where you are welcome to experiment with whatever.
- reader_mode 6y ago
  >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. Maximise your own happiness and your own knowledge, not the profit of your higher-ups. If you're a responsible adult you'll probably be the one who has to ship the stuff you started with the "flashy framework X" - boring technology is about maximising happiness - it just takes a while for this to sink in.
bottled_poe 6y ago
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.
Svip 6y ago
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.
- threeseed 6y ago
  Modern cars are far more efficient, performant and easier to drive than a 15 year one. Just like modern web apps are far more scalable, highly-available, secure and performant then they were 15 years ago.
  - sprkwd 6y ago
    It’s easier to fix 15+ Year old cars yourself.
    - IshKebab 6y ago
      How many people fix cars themselves?
    - mortehu 6y ago
      Agreed. I once owned a 30 year old two stroke moped. It was very easy to fix. In fact I fixed it almost every week.
    - XCSme 6y ago
      It's easier to not have to fix new cars.
    - oblio 6y ago
      It's also much easier to die in 15+ years old car.
  - tonyedgecombe 6y ago
    Yes, we just replaced our eleven year old car with a three year old. The same make and model and our fuel bill dropped by 25%. This is nearly half the cost of the car over the period we will own it.
iamacyborg 6y ago
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. They sure had fun building it though.
- threeseed 6y ago
  What does that even remotely have to do with micro-services or MongoDB ? If your query was exposed as a REST API you could have easily accessed it via a micro-service. And MongoDB has a pretty powerful and easy to use query language. I could've answered your query in about 5s. Sounds more like a business or process limitation.
  - iamacyborg 6y ago
    Just a generalised frustration that the technology team didn’t seem to understand how the rest of the business needed the technology to behave. The reality is you don’t need that sort of query exposed as an API, but you do need that data to be exported regularly into a CRM and marketing automation tools.
  - satyrnein 6y ago
    It seems like you're assuming the data you need is all in one microservice. (In which case, why did you need microservices?) Let's say the report needs data from across two microservices, one is backed by mongodb and one is mysql, and both services have been crud endpoints but not ones that will give you the full data you need. This is a pretty typical scenario! So you could make new endpoints, but then you still need to "join" the data in code. Or you could set up data pipelines to sync data into into a data warehouse, where you query across everything. Or you could have kept everything in a monolith, and this would have actually been a 5 second SQL query.
    - gaogao 6y ago
      Still a 5 second SQL query with Presto or similar and a warehouse.
qmmmur 6y ago
This has to be the worst website to get the most basic information. Talk about over-engineering.
qnsi 6y ago
So, what would be a best boring backend stack today? The one mentioned in the article? Or java for python?
- rakoo 6y ago
  The one you and your team master, where all the failing modes are known and predictable
srich36 6y ago
This is one of those posts where you can really feel the value of senior engineering/previous experience. 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).
phabora 6y ago
Really good presentation. Even in this form. These are the best arguments for choosing Boring Tech that I’ve seen yet. Almost gave me a sinking feeling: > 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. > 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.
- ywei3410 6y ago
  The hypothesis fails because it assumes all curves are the same - and all tech has the same number of kinks; which is patently false.
gscho 6y ago
I enjoy reading this each time it gets posted but can we please get TLS enabled? It's so easy these days.
- moonbug 6y ago
  but why.
  - hacker_newz 6y ago
    It is pretty embarrassing for someone in tech not to set up properly.
methyl 6y ago
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.
- atoav 6y ago
  I guess it goes like this: Is there much at stake? Choose a boring technology. Is it a experiment or a toy project? Choose whatever floats your boat, knock yourself out, have fun and learn on the way. Trying out new things makes a ton of sense. But trying them out in a domain where unforeseen consequences could potentially destroy you is not a smart move.
  - cutler 6y ago
    Since most commercial projects have much at stake how would new technologies ever get a chance to become mainstream? For this to happen there has to be some risk-taking otherwise we'll be permanently stuck in the current situation where a bunch of scripting languages designed in the mid-90s for single processors are tasked with handling much bigger workloads on multi-core machines. Hence the current wave of bolted-on gradual typing.
yters 6y ago
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?
- user5994461 6y ago
  I'm surprised one guy can bring in gitlab, openshift, and istio all by himself. They're not small things to setup and to migrate existing software to. Typically how this goes, few of the existing software migrate to the new stack (it's too much work to migrate and it doesn't work as well). After the guy is gone, you can deprecate the new stack immediately and don't bother supporting it. I've seen it happen a lot. What you don't say is how large the company is. For startups and small companies, my experience is that every generation of developers (couple years) will rewrite most of everything. That's just how things go in startup, filled by eager young folks who have no experience and build their resume. That's only possible because there isn't that much code in the first place. Larger companies can be stuck with multiple stacks because there's too many software to migrate and no sucker to do it. Older projects are stable and have no active developers working on them, they're not going to be rearchitectured. Other departments/developers know that they can't trust the shiny new tool from your department, that's going to be deprecated next year, they don't adopt in the first place (a great example of why large companies resist changes). It's just the state of the industry I guess. IMO it's crazy how few people working on tools/frameworks can inflict migrations on a hundred developers/projects (thousands in larger companies), often for no benefits. I realize this doesn't answer your question, how to help? No idea. Would be nice to cancel projects early before they reach that stage. It's probably too late now. What you can improve is your perception. If it makes you feel better, one pro of all this churn is that there are many more jobs, doing rewrites over and over again. It's nice to have a job in the current climate.
killingtime74 6y ago
Does using Java but with native image (compiled to binary) count as using an innovation token due to new packaging or no (due to Java?)
- gonzo41 6y ago
  It's a negative 1 because you could have made an EXE jar and run it with standard open jdk on the server.
  - killingtime74 6y ago
    True enough
- deleted 6y ago
  [deleted]
matthewfelgate 6y ago
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".
reader_mode 6y ago
> 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. >I don’t know if this makes sense for fashion or what have you, but I really think there is something to this. Johny Bravo was conserving his brainpower all along ! I kind of like this idea, will probably try this, jeans + long and short sleeved versions.
- mrtksn 6y ago
  If I remember correctly, that’s supposed to be the reason why Steve Jobs used to wear the same outfit all the time.
  - bitwize 6y ago
    Barack Obama had multiple copies of the same suit hanging in his closet. It was like Smurfette's closet. When the time came to make an appearance or do something presidential, he'd pick out a fresh suit and know exactly how he'd look in it.
- Aeolun 6y ago
  This works just as well with a slightly more diverse outfit. I have 3 pants, and 5 shirts, any combination between these is fine, so I just wear what isn’t being washed at the time.
chrischapman 6y ago
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.
- closeparen 6y ago
  I thought this was supposed to mean that the bold pilots died.
lovetocode 6y ago
What a great post! > 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. 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.
msvan 6y ago
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. 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. 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.
- Bakary 6y ago
  I don't know if freeloading is the appropriate concept here. A person making open source contributions will be happy to see people use their work. They won't worry about whether the typical user also contributes back. Most people don't have the capacity to make such a contribution. More broadly, the software industry "freeloads" over the work of all other workers who create a safe environment where food and energy is easily available. But the whole attraction of creating a society is to make life better eventually, otherwise we might as well have never left the savannah.
jmartrican 6y ago
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. 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. 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. 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.
- vasco 6y ago
  I agree completely. Another angle that is less common is remaining at one company you believe and respects your work. If you find somewhere like that, years of working in the same domain can make you more effective. Not to speak of the advantages of a team that works together for 5+ years and the power that comes from true camradarie with your team mates. It's sad that most places - and by definition the largest places also - end up being a meat grinder and people just hop companies and teams within companies every year or two. By the time you start understanding the domain you move on. It takes years to internalize a problem and understand it deeply.
  - jmartrican 6y ago
    So true. I feel empathy towards management that need to keep their engineering teams intact.
nkg 6y ago
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.
datavirtue 6y ago
So we should all embrace Oracle?
nathanganser 6y ago
And then it read "Attention is precious" and I realized I was losing my time and should got back to more important stuff :P
ahstilde 6y ago
(2015)
carapace 6y ago
"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? 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. 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.
altgans 6y ago
Two observations: - 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. - 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.
muramira 6y ago
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.
- XCSme 6y ago
  I decided to use MongoDB for a pretty big online multiplayer game and it worked very well, not many issues and the development time was a lot faster than trying to use SQL.
deleted 6y ago
[deleted]
siliconc0w 6y ago
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. 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.
deleted 6y ago
[deleted]
XCSme 6y ago
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. 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.
11thEarlOfMar 6y ago
> New tech typically has more known unknowns, and many more unknown unknowns. And this is really important. Isn't this true in many facets of life? Like.... taking a new job... having your first kid... visiting a new city... Are there processes for engaging in any new experience that enable you to know the outcome is going to be net positive before commencing?
onetom 6y ago
Is Clojure a boring technology yet? :)
- wilsonthewhale 6y ago
  I would argue yes. There has been an impressively little amount of churn in the last 10 years.
soheil 6y ago
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. 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.
pmohun 6y ago
This essay from David Perell touches on a similar concept: https://perell.com/note/lateral-thinking-with-withered-ideas/ https://perell.com/note/lateral-thinking-with-withered-ideas... > 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.
dang 6y ago
Choose Boring Technology (but not the same article) - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) The boring technology behind a one-person Internet company (2018) - https://news.ycombinator.com/item?id=20985875 https://news.ycombinator.com/item?id=20985875 - Sept 2019 (451 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments) Also: current ongoing thread Choose Exciting Technology - https://news.ycombinator.com/item?id=26212563 https://news.ycombinator.com/item?id=26212563
z3t4 6y ago
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.
kalalala087 6y ago
https://properfocusreview.medium.com/proper-focus-adjustable-glasses-reviews-728a0377e3b https://properfocusreview.medium.com/proper-focus-adjustable...
- kalalala087 6y ago
  https://patch.com/washington/seattle/classifieds/for-sale/204416/drone-x-pro-review-test-price-app-legitimate https://patch.com/washington/seattle/classifieds/for-sale/20...
revskill 6y ago
Technology is just a tool, or not ? By a tool, i mean, we still use boring algorithms (which exist long before the tech is born to adapt it efficiently). So, boring tech or not, it's not the point, as long as it serve your purpose.
kingkawn 6y ago
Black t-shirt guy is onto something...
0xCMP 6y ago
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.
nine_k 6y ago
The title of this article, which makes rounds on HN, bothers me. It's not about choosing a "boring" tech. It's about choosing tools you understand well and a master of. 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. Choosing a perfectly boring thing like Cobol is not going to help if you have no solid mainframe experience.
- jonahx 6y ago
  From the article: > I chose “boring technology” as the pithy SEO-friendly title for this content, and I regret it most days. It’s kind of distracting. “Boring sounds bad, why is he saying it’s good?” Et cetera. It’s a real shitshow. > But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. > It’s important to master the tools that you do pick.
golemiprague 6y ago
Useless advice of the type of "choose the right tool for the task", what is boring? what is the right tool? That's always the question, not the answer. There are also so many other variables to decide success and outcome that I am not sure anyone can point their finger to the technology stack and certainly claim that it is the cause of this or that.
deleted 6y ago
[deleted]
pharmakom 6y ago
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.
mikesabbagh 6y ago
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
syastrov 6y ago
Reading this sounds like dejavu. 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. 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. 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. 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.
elonvolo 6y ago
There’s a lot of social status and perception-shaping tied up in who gets to do what innovation. 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.
jariel 6y ago
One thing missing from the essay: If you hire people that are more interested in solving the problem, then they are the tech ... the problem goes away. Using some 'fancy, risk new thing' has utterly no appeal to someone trying to do XYZ by a certain time with a certain quality. This is one of the biggest dissonances between Eng. and many business roles. 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. 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'.
BerislavLopac 6y ago
As I commented on Quora [0] a while ago: That is basically the inverse of Clarke’s First Law: Any sufficiently understood magic is indistinguishable from boring technology. [0] 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 https://www.quora.com/Are-Google-software-engineers-really-d...

603 points by asyrafql 6y ago

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. 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.

the_gipsy 6y ago
Especially when he said that some people did have to work on that setup to scale it up. Sounds like devops work, so the same would have happened with redis, right?
- CamouflagedKiwi 6y ago
  He covers this - the operational setup & expertise to scale Memcached already existed because Etsy already used it elsewhere. It would have had to be built and learned (mostly) separately for Redis.
  - the_gipsy 6y ago
    I meant the part where he talks about maintenance later on.
    - ryanbrunner 6y ago
      Maintenance is also something that has to be learned (and "built up" in the sense that you're going to accumulate playbooks and processes over time). If a team already existed that knew the ins and outs of memcached, knew how to resolve any problems it encountered, already had appropriate monitoring / alarms / etc, that's a massive leg up over needing to do all that with a completely new technology.

fiftyacorn 6y ago

I still think the Simplicity Chapter in the Google SRE book sums this up best https://sre.google/sre-book/simplicity/ https://sre.google/sre-book/simplicity/

polote 6y ago

previous discussion (348 comments) https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246

jsnell 6y ago
Also: https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215

phendrenad2 6y ago

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. 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. 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? Anyway, this is a cool website, and it'll be useful to point people to it in the future, so thanks for that.

Mikushi 6y ago
> The last line of defense against a rogue engineering team is managers who have studied this stuff. If your engineering team is the one pushing in that direction I'd reckon the company was in a bad spot to begin with to have hired that team because it strongly indicates that the management layer (head of tech/CTO) has no technical clue. Hire strong Lead Developers with a proven track record of delivering value to companies they worked at and you'll be mostly fine. Also there's not much to study, in 99% of the cases in a web based startup if your stack deviates from a monolith with one of PHP/Ruby/Python/.NET/Go + Mysql/Postgres/MSSQL you're doing it wrong.
- js4ever 6y ago
  What's wrong with Node.js? It's super mainstream now. We have it in production since years, I see a LOT of companies migrating from everything else to node since years and it's a growing trend from what I see at my level with startups and even enterprises

trestenhortz 6y ago

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. 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. When someone comes at your approach wielding a slogan, be skeptical.

krenel 6y ago
> When someone comes at your approach wielding a slogan, be skeptical. I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things. Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"
- trestenhortz 6y ago
  Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.
  - krenel 6y ago
    I would agree that we're talking about the same thing, really: > The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.
  - sverhagen 6y ago
    It may. But probably it doesn't. Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.

tpetry 6y ago

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. 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. 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.

threeseed 6y ago
Basecamp is a simple app though. Ridiculously simple. That app could have been written in the mid-1990s using WebObjects in just a few months. Technologies like MongoDB, React, GraphQL, Microservices etc exist because modern, real-world apps are generally far more advanced than just a glorified CRUD app. Consumers simply have higher expectations and more demands for what web apps should be able to do.
- overkalix 6y ago
  > modern, real-world apps are generally far more advanced than just a glorified CRUD app. ... are they?
  - reasonabl_human 6y ago
    ...yes
- ryanbrunner 6y ago
  While this is somewhat true and you can't solve everything with Rails + Postgres, you should ask yourself very, very hard about whether what you're building is in that category (and further, whether every part of what you're building falls into that category). Far, far too often I think a significant source of complexity is enthusiastically added by engineers themselves assuming that the problem they're solving is sufficiently complex that boring technologies just aren't up to the requirements of their project. My current gig is writing a very traditional Rails app (we hardly even dabble in Stimulus or Javascript all that much). Prior to that, I worked on a Javascript-backed fully reactive real-time app using the latest and greatest of technologies. My boring old Rails app, IMHO, has a much nicer user experience, far fewer quality issues, and is well loved by customers, where the bleeding edge Javascript app was constantly deried by customers for being difficult to use, buggy and unintuitive. You can go a long way with simple technologies if you design your experiences well.

the_gipsy 6y ago

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.

jeromenerf 6y ago
In my experience "boring" is less correlated to "shitty tech" than poor organization. Most dev work is "blue collar" work, following top down business decisions. The opportunities for devs to push impactful bottom up projects for a company business are rare at best. I have always preferred organizations where business problems-to-solve were pushed top-down rather than executive decisions. It encourages business understanding, initiatives and ownership.
- phabora 6y ago
  Blue collar is not a synonym for subordinate.
ryanbrunner 6y ago
I don't think this has to be true. I've worked in many places (granted, smallish teams of less than 20 or so) where tech decisions were made collectively, without even that much input from the CTO. Choosing boring technology doesn't have to be a top down thing, although it probably needs to have some mechanism for aligning a whole team (since 10 different "boring technologies" are no longer boring and bring along all the problems of using shiny new toys).
datavirtue 6y ago
Dude, you can go home and play with any toy you want.

wrnr 6y ago

This stack can be radically simplified: Apache: managing open connections. Memcache: holding stuff in memory. Postgresql: Save stuff to disk. Cron: Schedule things. Python: wire the above things together ... or a good reason the pick Go or Java

hnedeotes 6y ago
Or better, Elixir + Postgresql
- nhumrich 6y ago
  Not sure elixir qualifies as "old and boring tech"
  - yellowapple 6y ago
    Elixir, probably not. Erlang (and more broadly OTP), however, definitely qualifies IMO, at least depending on point of view. And given that Elixir is just an alternate language targeting OTP on Erlang's VM, there ain't much stopping folks from treating it as exactly that (and sticking with things like Yaws and Mnesia/CouchDB instead of the latest Phoenix hotness).
  - hnedeotes 6y ago
    (this got out of hand...) I understand what you're saying and think you're right, in terms of not having had the same time running in the wild to have the same knowledge base and ecosystem as other solutions. But looking at what it actually is, it's a layer over the much older underlying technology, which is Erlang, once you look at the frameworks used, they are basically implementations of things we consider old approaches, despite including new features. Some examples: - Phoenix - it's a MVC framework, it's not much different from any MVC framework except it doesn't have the "model". You can entirely use it in that "boring" CRUD app way and it will be a great choice. It's performant and has a templating system for HTML, a plug system that looks like middlewares. But if you need to use web sockets without ceremony or want to try something shiny like live views, you can as well. You're not forced to though and you don't need to use nodejs for your js either (as an example) - Ecto - It looks like an ORM but isn't an ORM, it's default choice for database is Postgresql. It's a library that mimics SQL itself (the helpers and the way you use it are as they would be used in SQL but designed to be chain able and sanitised), it also has easy ways of executing SQL while still sanitising it and also of writing raw SQL. So, pretty boring in all senses except the slight change in syntax to write the queries in elixir. This means for instance a distinct clause would be distinct(query, [table_mentioned_in_query], asc: table_mentioned_in_query.platform) This is not written as sql, but it maps to sql one to one. It uses schemas which are just that, schemas that map how values are dumped and cast from the DB, they're not models/objects, they're just data structures. But if you want to get fancy it also has embedded schemas if you want to use jsonb for instance, that allow you to use jsonb columns while still maintaining a "typed" schema from dump to read. What may look a bit alien is perhaps the access to OTP libraries that Erlang offers, the way the VM works and certain abilities that come from the way you will structure an app, but even those when we think about them, it's basically what any OS does, or the way kernels work. You have processes, they have identifiers, you can name them, you can run a lot of them concurrently, they can have separate lifecycle trees/dependencies, they have interfaces, you pass "messages" between them. Maybe what's "new" when you compare it to other languages is that this is not usually available to them but I would argue that most of our systems are implemented exactly in that way because it's the most reasonable outside very specific constraints/needs. When you use Elixir, Phoenix and Ecto you don't need to use these (or understand them deeply), usually the libraries take care of that for you. You can start as if you were writing a nodejs, rails, .net, python or whatever application. But then if you actually need you have a host of utilities and a runtime that I think is excellent for the kind of things most apps out there need, in a single runtime, and you can take it pretty far before you need to extend the stack and that has value in itself I think.

solanav 6y ago

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. 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.

WJW 6y ago
Boring technology also has the benefit of not waking you up in the middle of the night as often, because most of the weird bugs have been rooted out by other people. This can also be a downside of course, depending on how your particular org rewards "firefighters".
serial_dev 6y ago
Totally, one can understand both sides. In my opinion, it also works in the other direction, where the managers push things onto the developers. "Can we use this blockchain thing?", "we need to do AI", "we should use this cross platform mobile app tool I heard and read 3 minutes about".
cjfd 6y ago
Actually, also as an engineer much happiness comes from shipping products. Also, happiness comes from programming as opposed to configure and/or repearing a baroque tech stack with technologies that are not needed anyway but still break every other week. The latter thing comes with anger and the desire to scold (if not worse) the persons who needlessly brought in the complexity. If you want to learn new things there is your spare time where you are welcome to experiment with whatever.
reader_mode 6y ago
>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. Maximise your own happiness and your own knowledge, not the profit of your higher-ups. If you're a responsible adult you'll probably be the one who has to ship the stuff you started with the "flashy framework X" - boring technology is about maximising happiness - it just takes a while for this to sink in.

bottled_poe 6y ago

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.

Svip 6y ago

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.

threeseed 6y ago
Modern cars are far more efficient, performant and easier to drive than a 15 year one. Just like modern web apps are far more scalable, highly-available, secure and performant then they were 15 years ago.
- sprkwd 6y ago
  It’s easier to fix 15+ Year old cars yourself.
  - IshKebab 6y ago
    How many people fix cars themselves?
  - mortehu 6y ago
    Agreed. I once owned a 30 year old two stroke moped. It was very easy to fix. In fact I fixed it almost every week.
  - XCSme 6y ago
    It's easier to not have to fix new cars.
  - oblio 6y ago
    It's also much easier to die in 15+ years old car.
- tonyedgecombe 6y ago
  Yes, we just replaced our eleven year old car with a three year old. The same make and model and our fuel bill dropped by 25%. This is nearly half the cost of the car over the period we will own it.

iamacyborg 6y ago

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. They sure had fun building it though.

threeseed 6y ago
What does that even remotely have to do with micro-services or MongoDB ? If your query was exposed as a REST API you could have easily accessed it via a micro-service. And MongoDB has a pretty powerful and easy to use query language. I could've answered your query in about 5s. Sounds more like a business or process limitation.
- iamacyborg 6y ago
  Just a generalised frustration that the technology team didn’t seem to understand how the rest of the business needed the technology to behave. The reality is you don’t need that sort of query exposed as an API, but you do need that data to be exported regularly into a CRM and marketing automation tools.
- satyrnein 6y ago
  It seems like you're assuming the data you need is all in one microservice. (In which case, why did you need microservices?) Let's say the report needs data from across two microservices, one is backed by mongodb and one is mysql, and both services have been crud endpoints but not ones that will give you the full data you need. This is a pretty typical scenario! So you could make new endpoints, but then you still need to "join" the data in code. Or you could set up data pipelines to sync data into into a data warehouse, where you query across everything. Or you could have kept everything in a monolith, and this would have actually been a 5 second SQL query.
  - gaogao 6y ago
    Still a 5 second SQL query with Presto or similar and a warehouse.

qmmmur 6y ago

This has to be the worst website to get the most basic information. Talk about over-engineering.

qnsi 6y ago

So, what would be a best boring backend stack today? The one mentioned in the article? Or java for python?

rakoo 6y ago
The one you and your team master, where all the failing modes are known and predictable

srich36 6y ago

This is one of those posts where you can really feel the value of senior engineering/previous experience. 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).

phabora 6y ago

Really good presentation. Even in this form. These are the best arguments for choosing Boring Tech that I’ve seen yet. Almost gave me a sinking feeling: > 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. > 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.

ywei3410 6y ago
The hypothesis fails because it assumes all curves are the same - and all tech has the same number of kinks; which is patently false.

gscho 6y ago

I enjoy reading this each time it gets posted but can we please get TLS enabled? It's so easy these days.

moonbug 6y ago
but why.
- hacker_newz 6y ago
  It is pretty embarrassing for someone in tech not to set up properly.

methyl 6y ago

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.

atoav 6y ago
I guess it goes like this: Is there much at stake? Choose a boring technology. Is it a experiment or a toy project? Choose whatever floats your boat, knock yourself out, have fun and learn on the way. Trying out new things makes a ton of sense. But trying them out in a domain where unforeseen consequences could potentially destroy you is not a smart move.
- cutler 6y ago
  Since most commercial projects have much at stake how would new technologies ever get a chance to become mainstream? For this to happen there has to be some risk-taking otherwise we'll be permanently stuck in the current situation where a bunch of scripting languages designed in the mid-90s for single processors are tasked with handling much bigger workloads on multi-core machines. Hence the current wave of bolted-on gradual typing.

yters 6y ago

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?

user5994461 6y ago
I'm surprised one guy can bring in gitlab, openshift, and istio all by himself. They're not small things to setup and to migrate existing software to. Typically how this goes, few of the existing software migrate to the new stack (it's too much work to migrate and it doesn't work as well). After the guy is gone, you can deprecate the new stack immediately and don't bother supporting it. I've seen it happen a lot. What you don't say is how large the company is. For startups and small companies, my experience is that every generation of developers (couple years) will rewrite most of everything. That's just how things go in startup, filled by eager young folks who have no experience and build their resume. That's only possible because there isn't that much code in the first place. Larger companies can be stuck with multiple stacks because there's too many software to migrate and no sucker to do it. Older projects are stable and have no active developers working on them, they're not going to be rearchitectured. Other departments/developers know that they can't trust the shiny new tool from your department, that's going to be deprecated next year, they don't adopt in the first place (a great example of why large companies resist changes). It's just the state of the industry I guess. IMO it's crazy how few people working on tools/frameworks can inflict migrations on a hundred developers/projects (thousands in larger companies), often for no benefits. I realize this doesn't answer your question, how to help? No idea. Would be nice to cancel projects early before they reach that stage. It's probably too late now. What you can improve is your perception. If it makes you feel better, one pro of all this churn is that there are many more jobs, doing rewrites over and over again. It's nice to have a job in the current climate.

killingtime74 6y ago

Does using Java but with native image (compiled to binary) count as using an innovation token due to new packaging or no (due to Java?)

gonzo41 6y ago
It's a negative 1 because you could have made an EXE jar and run it with standard open jdk on the server.
- killingtime74 6y ago
  True enough
deleted 6y ago
[deleted]

matthewfelgate 6y ago

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".

reader_mode 6y ago

> 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. >I don’t know if this makes sense for fashion or what have you, but I really think there is something to this. Johny Bravo was conserving his brainpower all along ! I kind of like this idea, will probably try this, jeans + long and short sleeved versions.

mrtksn 6y ago
If I remember correctly, that’s supposed to be the reason why Steve Jobs used to wear the same outfit all the time.
- bitwize 6y ago
  Barack Obama had multiple copies of the same suit hanging in his closet. It was like Smurfette's closet. When the time came to make an appearance or do something presidential, he'd pick out a fresh suit and know exactly how he'd look in it.
Aeolun 6y ago
This works just as well with a slightly more diverse outfit. I have 3 pants, and 5 shirts, any combination between these is fine, so I just wear what isn’t being washed at the time.

chrischapman 6y ago

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.

closeparen 6y ago
I thought this was supposed to mean that the bold pilots died.

lovetocode 6y ago

What a great post! > 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. 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.

msvan 6y ago

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. 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. 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.

Bakary 6y ago
I don't know if freeloading is the appropriate concept here. A person making open source contributions will be happy to see people use their work. They won't worry about whether the typical user also contributes back. Most people don't have the capacity to make such a contribution. More broadly, the software industry "freeloads" over the work of all other workers who create a safe environment where food and energy is easily available. But the whole attraction of creating a society is to make life better eventually, otherwise we might as well have never left the savannah.

jmartrican 6y ago

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. 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. 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. 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.

vasco 6y ago
I agree completely. Another angle that is less common is remaining at one company you believe and respects your work. If you find somewhere like that, years of working in the same domain can make you more effective. Not to speak of the advantages of a team that works together for 5+ years and the power that comes from true camradarie with your team mates. It's sad that most places - and by definition the largest places also - end up being a meat grinder and people just hop companies and teams within companies every year or two. By the time you start understanding the domain you move on. It takes years to internalize a problem and understand it deeply.
- jmartrican 6y ago
  So true. I feel empathy towards management that need to keep their engineering teams intact.

nkg 6y ago

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.

datavirtue 6y ago

So we should all embrace Oracle?

nathanganser 6y ago

And then it read "Attention is precious" and I realized I was losing my time and should got back to more important stuff :P

ahstilde 6y ago

(2015)

carapace 6y ago

"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? 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. 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.

altgans 6y ago

Two observations: - 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. - 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.

muramira 6y ago

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.

XCSme 6y ago
I decided to use MongoDB for a pretty big online multiplayer game and it worked very well, not many issues and the development time was a lot faster than trying to use SQL.

deleted 6y ago

[deleted]

siliconc0w 6y ago

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. 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.

deleted 6y ago

[deleted]

XCSme 6y ago

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. 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.

11thEarlOfMar 6y ago

> New tech typically has more known unknowns, and many more unknown unknowns. And this is really important. Isn't this true in many facets of life? Like.... taking a new job... having your first kid... visiting a new city... Are there processes for engaging in any new experience that enable you to know the outcome is going to be net positive before commencing?

onetom 6y ago

Is Clojure a boring technology yet? :)

wilsonthewhale 6y ago
I would argue yes. There has been an impressively little amount of churn in the last 10 years.

soheil 6y ago

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. 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.

pmohun 6y ago

This essay from David Perell touches on a similar concept: https://perell.com/note/lateral-thinking-with-withered-ideas/ https://perell.com/note/lateral-thinking-with-withered-ideas... > 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.

dang 6y ago

Choose Boring Technology (but not the same article) - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) The boring technology behind a one-person Internet company (2018) - https://news.ycombinator.com/item?id=20985875 https://news.ycombinator.com/item?id=20985875 - Sept 2019 (451 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments) Also: current ongoing thread Choose Exciting Technology - https://news.ycombinator.com/item?id=26212563 https://news.ycombinator.com/item?id=26212563

z3t4 6y ago

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.

kalalala087 6y ago

https://properfocusreview.medium.com/proper-focus-adjustable-glasses-reviews-728a0377e3b https://properfocusreview.medium.com/proper-focus-adjustable...

kalalala087 6y ago
https://patch.com/washington/seattle/classifieds/for-sale/204416/drone-x-pro-review-test-price-app-legitimate https://patch.com/washington/seattle/classifieds/for-sale/20...

revskill 6y ago

Technology is just a tool, or not ? By a tool, i mean, we still use boring algorithms (which exist long before the tech is born to adapt it efficiently). So, boring tech or not, it's not the point, as long as it serve your purpose.

kingkawn 6y ago

Black t-shirt guy is onto something...

0xCMP 6y ago

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.

nine_k 6y ago

The title of this article, which makes rounds on HN, bothers me. It's not about choosing a "boring" tech. It's about choosing tools you understand well and a master of. 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. Choosing a perfectly boring thing like Cobol is not going to help if you have no solid mainframe experience.

jonahx 6y ago
From the article: > I chose “boring technology” as the pithy SEO-friendly title for this content, and I regret it most days. It’s kind of distracting. “Boring sounds bad, why is he saying it’s good?” Et cetera. It’s a real shitshow. > But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. > It’s important to master the tools that you do pick.

golemiprague 6y ago

Useless advice of the type of "choose the right tool for the task", what is boring? what is the right tool? That's always the question, not the answer. There are also so many other variables to decide success and outcome that I am not sure anyone can point their finger to the technology stack and certainly claim that it is the cause of this or that.

deleted 6y ago

[deleted]

pharmakom 6y ago

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.

mikesabbagh 6y ago

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

syastrov 6y ago

Reading this sounds like dejavu. 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. 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. 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. 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.

elonvolo 6y ago

There’s a lot of social status and perception-shaping tied up in who gets to do what innovation. 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.

jariel 6y ago

One thing missing from the essay: If you hire people that are more interested in solving the problem, then they are the tech ... the problem goes away. Using some 'fancy, risk new thing' has utterly no appeal to someone trying to do XYZ by a certain time with a certain quality. This is one of the biggest dissonances between Eng. and many business roles. 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. 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'.

BerislavLopac 6y ago

As I commented on Quora [0] a while ago: That is basically the inverse of Clarke’s First Law: Any sufficiently understood magic is indistinguishable from boring technology. [0] 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 https://www.quora.com/Are-Google-software-engineers-really-d...