35 ms·

Choose Boring Technology

• dang 7y ago
  Discussed at the time: https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215
• dm3 7y ago
  Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume. Great that he's spreading the word!
  • tw1010 7y ago
    History is filled with re-discovery and explanation of things that were blindingly obvious to the generation that came before.
    • endymi0n 7y ago
      "Those who cannot remember the past are condemned to repeat it." ― George Santayana "I've got news for Mr. Santayana: we're doomed to repeat the past no matter what. That's what it is to be alive." ― Kurt Vonnegut
      • amelius 7y ago
        There's even an expression for it: reinventing the wheel.
        • enriquto 7y ago
          No, reinventing the wheel is alright; at best you may find a new and better kind of wheel, at worst you'll still learn something. This is forgetting that wheels can be round.
          • pnongrata 7y ago
            Thus, reinventing it, no?
            • close04 7y ago
              Learning from the past isn't to prevent you from reinventing the wheel but from reinventing the pothole.
              • snthd 7y ago
                Nothing wrong with reinventing potholes... https://www.indy100.com/article/this-man-is-painting-penises-on-potholes-so-the-council-has-to-take-action--ekSuZ63mgW https://www.indy100.com/article/this-man-is-painting-penises...
                • close04 7y ago
                  Only for those who don't understand the euphemism :). That guy actually learned from past mistakes and avoided reinventing them (methods that never worked). What the original saying is about is pretty clear from the words "condemned" or "doomed" to repeat it (depending on the version). [0] The saying is not about "reinventing the wheel" as in "refining/reinventing something already positive". It's trying to steer people away from major mistakes. Like ones that lead to great human tragedies and loss. Of course, everything can scale, it can affect an individual or the whole world. [0] https://en.wikiquote.org/wiki/George_Santayana#Vol._I,_Reason_in_Common_Sense https://en.wikiquote.org/wiki/George_Santayana#Vol._I,_Reaso...
          • schwurb 7y ago
            Our lifetime is finite. Given the choice, I'd rather invent the car than reinvent the wheel.
            • enriquto 7y ago
              It's nice that different people have different interests. I, for one, find materials science fascinating and car engineering rather bland.
        • diroussel 7y ago
          The funny thing about that expression is that wheels have never been reinvented. As far as we know. The Summarians had them, and the technology spread through contract with other civilizations. But not as far as we know re-invented anywhere else.
          • pjmlp 7y ago
            I think people at the same epoch living in other continents did reinvent them.
            • core-questions 7y ago
              That's independent invention, not re-invention. Reinvention requires that you could conceivably be aware of / be using an existing technology, but instead you choose to create it from scratch yourself.
              • pjmlp 7y ago
                Fair enough, I guess you're right.
      • deleted 7y ago
        [deleted]
      • loco5niner 7y ago
        On an individual level, Vonnegut is wrong. On a societal level, he is right. Santayana is still right.
      • yellowapple 7y ago
        "Those who can remember the past are condemned to watch everyone else repeat it." -- I have no idea who originally said this, and DuckDuckGo doesn't seem to be especially helpful in enlightening me on the origin of this particular corollary to Santayana's quote
  • murgindrag 7y ago
    I thought this was one of the best articulations, though. All it needs is a CC-BY-SA license so it can be used outside of one blog.
  • crispyambulance 7y ago
    Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on the problem at hand, we would be producing sad, boring things. If you want to see what that's like look at enterprise applications.
    • freetime2 7y ago
      It may not be sexy, but a good chunk of civilization runs on sad, boring enterprise applications. I for one am proud to build apps that are useful enough that businesses are willing to spend a large amount of effort and money to use them. Even if they are so ugly that they occasionally cause users’ eyeballs to bleed.
    • Erlich_Bachman 7y ago
      In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. Not only a liability, but a liability among other things.
      • jasode 7y ago
        >In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. That's an unbalanced conclusion. Code can be a liability but it can also be an asset. Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel efficiency is improved over older "non-computer-code" carburetors. Computer code is an asset that's equivalent to discovering new proven oil reserves. How about the limited resource of bandwidth on networks? Code and algorithms like h.264/h.265 that shrinks video enough to make it practical to stream to homes maximizes the existing network without having to lay a bunch of new fiber optic cables to every house. And consider all these YC companies that aren't worth much today. How do they become more valuable? They need to write more code. New features that customers find valuable requires coding. Even if the startup's code does not have patents, it will still be part of the tech portfolio assets that the acquiring company will include in the purchase. The "code is a liability" seems to be true if one limits their focus to negative situations like npm leftpad and the Boeing MCAS accidents. In contrast, I don't think the astronauts thought the Apollo Guidance Computer was a liability if it helps them get to the moon.
  • agumonkey 7y ago
    chasing trends is a problem but suffering java <5 too You can deliver so much more, so much safer using other techniques...
    • asdfman123 7y ago
      I think it makes sense to keep up with the latest version of the programming language you use, and keep updating the codebase. The important part is not introducing an entirely new language that no one knows, or changing around the entire architecture without really being able to understand the long term consequences. Also, after moving to C#, I don't know why anyone uses plain old Java anymore. C# runs on Linux now. It's not the 90s anymore. Oracle is the dinosaur and MS now is kind to its developers. Plus I'm hoping that client-side C# will take off with WebAssembly.
      • delusional 7y ago
        > The important part is not introducing an entirely new language that no one knows > I don't know why anyone uses plain old Java anymore You see, if we refuse to change, we can't ever get better.
        • asdfman123 7y ago
          Sorry, I meant on new projects. I'm not talking about using the latest and shiniest thing, I mean using C# or Python or some other language. However if youre strongest in Java then you should probably do Java.
      • guitarbill 7y ago
        As a previous fan of C# and a long time Java sufferer, I'm pretty sure it's too little, too late for C#. Sadly, years of being locked to Windows has stunted the C# ecosystem and given Java enough time to get less horrible. Java 8+ is okay. Lombok helps. There's other great, mature libraries around. There's a choice of IDEs. There's JREs to choose from - there's even JVMs to choose from. Gradle makes build files not suck and makes it easy to add static checking and linting to the build process. AFAIK, C# doesn't have auto-formatting options outside the IDE. As much as I used to have your view, Java is alive, works fine, and makes money. Or Minecraft mods.
  • rb808 7y ago
    > you're supposed to solve problems instead of chasing trends and padding the resume Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!
    • tzakrajs 7y ago
      Agree, commenter above you might have thought resumes and interviews are related to the job we ought to be doing and they aren’t.
  • rolltiide 7y ago
    I think the best example of this is IDE and text editor preferences. They are totally regional, programming-language subculture, and age related The proponents of Atom/VSCode/Sublime/VIM etc will swear by it to the level of gatekeeping other competent software engineers away from them if they don't use that particular editor, and they all do - or can do - the same thing.
  • esoterica 7y ago
    No, your mandate is to advance your career, not solve problems. If you’re rewarded for resume padding more than problem solving then keep resume padding.
    • ozim 7y ago
      It is nice to be idealistic, but what you wrote is true. Just like people think companies are doing best things for their customers. Companies do what is best for them, and it happens to align with what customers need, sometimes it is better for company to do something that is not good for their customers. The same applies to employees, most of the time what you do aligns with company goals, but when it does not, you have to change job or do something else.
• ForHackernews 7y ago
  It seems like a lot of this is just the tension between what management wants to be focusing on (big picture product or business-level questions) vs what it makes sense for individual engineers to be focusing their efforts on. As an individual contributor, it's vitally important to keep up with new technologies in order to remain employable. Maybe that isn't in fact the best strategy for your current job, but it's crucial to getting your next job. Put another way, there are probably a lot of businesses that sensibly standardized on ColdFusion in the early 2000s. Engineers who buckled down and focused on "So what’s your company trying to do?" using CFML could easily find themselves in a really bad spot--unless they were also sacrificing their home life to teach themselves something else.
  • cutler 7y ago
    If it's vitally important to keep up with new technologies in order to remain employable why are the 7 most employable programming languages (C,C++,Java,PHP,JS,Ruby,Python) at least 25 years old? The job market says the opposite - that new programming languages hardly get a look-in.
    • ForHackernews 7y ago
      Programming languages alone aren't the only things you have to know in order to be a professional developer. It's also important to keep up with the ecosystem around that language, and industry-wide trends in application design, testing and deployment/ops. Good luck getting a Javascript job if all you know is jQuery, and you've never touched Webpack/React/whatever else JS devs need these days. Maybe JS is an extreme case, but some version of that same phenomenon exists for all the languages you mentioned.
• neilwilson 7y ago
  There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS with some whizzy Javascript interface library. Over time it becomes harder and harder and more and more expensive to maintain old technology. Because frankly maintaining old technology is pretty boring and career destroying so you need to be paid more and more to do it. The marginal benefit of the new shiny is indeed an overhead you should try and avoid, but also you have to dodge the trap of being stuck in a technology when everybody else has moved on. Anyway back to the Adabas support...
  • Cthulhu_ 7y ago
    Well you can sit down and do the maths; you mention Cobol, which you can actually map to the cost and availability of developers. The cost of that technological choice just keeps growing and growing. You can compare that to the cost of converting it to e.g. Java (and multiply that cost by 2-5x because it's very hard to make an accurate guess). This goes for all technological choices. The cost is not static, but varies over time depending on market forces.
    • carlmr 7y ago
      If everybody stayed with the boring tech, cobol developers would be abundant and cheap.
  • vasco 7y ago
    2-3 years after you read it on Hackernews is a good rule of thumb.
  • openfuture 7y ago
    You never change, at some point a competitor arises that chose different technology and it kills you.
    • sametmax 7y ago
      Competitors don't kill you because they chose a new tech. They kill you because they can either: - solve a new problem - solve an existing problem better - solve an existing problem cheaper A new tech MAY allow that, and it MAY be used successfully toward that objective, but even in that case, that's hardly the core of it for most cases. Not saying it does not happen, but there are much more at play.
• syntheticnature 7y ago
  (2018)
• edynoid 7y ago
  Interesting… most of the motivation to use new tech is that it enables me to solve problems more efficiently. When you use older, but more established technology, its limitations still hold back the problem solving a bit. This is especially hard to take when I know there are better solutions out there. And it also costs more time & money. There probably is a pain point somewhere, where it makes sense to switch. I did like the point about reducing the cost of new technology – that may be quite often easier said than done though.
  • Zelphyr 7y ago
    But the pain points of older technology are known whereas those of newer tech aren’t yet.
• billysielu 7y ago
  is there a video of this being presented somewhere?
  • oftenwrong 7y ago
    https://www.youtube.com/watch?v=wUmx-dlYS34 https://www.youtube.com/watch?v=wUmx-dlYS34
• jasode 7y ago
  As a meta observation, I noticed this was submitted by user luu and his website also has a blog post with a similar theme ("boring languages"[1]). Therefore, I wonder if the "boring vs exciting" advice somewhat depends on the personality. I.e. if person has a tendency to prefer conservative technology, it means external advice that advocates "boring tech" will resonate with that person. I think choosing boring technology makes sense but I'll give a contrarian view anyway. A lot of people like new and shiny things because it's interesting and spurs the imagination for future work. For example, in 1974 when the new Altair 8800 made the cover of Popular Electronics[2], an excited Paul Allen showed the magazine to a 19-year old Bill Gates. The "boring tech" advocates would tell them they're wasting their time with the "new fad of microcomputers" and they should look at boring IBM 360 mainframes instead. Those IBM machines were around since the 1960s and were more proven. The problem is that Bill and Paul weren't interested in those mainframes. The choice isn't proven/unproven. The choice was really interested/uninterested. Similar situation with WhatsApp in 2009. Apple just released the iPhone SDK in 2008. The older tech was PalmOS, Windows Mobile CE, and Symbian. Those legacy mobile operating systems were around since the 1990s. It didn't matter to Jan Kuom that the new iPhone didn't have a track record. It was the more interesting platform to work on and he made a bet to write an app for it. From what I read, Google's first AdWords server in 2000 was built on MySQL. MySQL was released in 1995 so using a relatively new 5-year old technology may have been more risky than picking traditional Oracle RDBMS which had been around since the late 1970s. It's ok to choose new and unproven tech if you have a coherent thesis of why it makes sense to try it. You also have to be willing to pay the price if your bet turns out to be wrong. You can also deliberately choose boring tech in as many areas as possible so it frees up brainpower to aggressively make a bet on new unproven tech in a particular area where you think it will make a difference. Also, your role dictates the freedom to use new and unproven tech. If you're an employee at a mature and conservative company, you'll be constrained to choose boring technology to minimize risk. (This reinforces the saying, "Nobody ever got fired for buying IBM.") On the other hand, if you're an entrepreneur, there's a good chance you'll need to make a calculated risk with new exciting technology that is (1) unproven, (2) has non-existent documentation, (3) does not have much tooling to make implementation easy. At one point, even all the "boring technology" was new and interesting. In 2019, what's some new and unproven tech that we should look at? [1] https://danluu.com/boring-languages/ https://danluu.com/boring-languages/ [2] https://www.google.com/search?q=altair+8800+magazine+cover&source=lnms&tbm=isch https://www.google.com/search?q=altair+8800+magazine+cover&s...
• ChrisSD 7y ago
  Is this about BoringSSL or The Boring Company? There's so many new and exciting boring technologies to follow that it's hard to keep track.
  • deleted 7y ago
    [deleted]
• mlosapio 7y ago
  This is a fantastic piece! I’ve been advocating for “complexity points” for years now. MBSA (make boring sexy again!)
• notinversed 7y ago
  I get so excited when I see a page that renders immediately with server side markup, it’s a rare old treat.
• deleted 7y ago
  [deleted]
• TickleSteve 7y ago
  The phrase "Bleeding edge" was coined for a reason... The HN audience typically lives at the bleeding edge and assumes the world does too.
• joaodlf 7y ago
  I am more and more resonating with these feelings, for the good and bad. In fact, my own writing reflects that over the years: https://joaodlf.com/ https://joaodlf.com/ , I started my blog with information regarding technologies like Spark, Cassandra, Go, etc, and I am now writing about Postgres and Python web dev and Celery. Boring is boring but it simplifies so much. I still love new technology, but I am now much more likely to try it out extensively and privately before even dreaming of bringing it to my company. An example: A few years ago I got very excited about Go, I started introducing it at work and solved some difficult issues with it. I could not get the rest of the developers to gain an interest in the language, though. Effectively, no one else but me could touch any of that code, this is not good for business. I have now revamped that same code, using old technology, and learned a lot along the way - so much so that I now feel like this old tech behaves as nicely as the more complicated, flashy, new language implementation.
  • salixrosa 7y ago
    I literally had this conversation yesterday as a "why I'm not sure web development is for me, long-term." The level of familiarity that can be achieved with a tool in the timeframe allotted before the "oh no, we're behind-the-times!" fervor strikes just doesn't seem sufficient to me. I'll have co-workers coming to me with the tool-specific roadblocks they're hitting, and have reached the point where I can easily say "yeah, I've been there, you'd never guess but the problem is with [X], just do [Y]." And just as I'm getting really efficient, I've got to throw it all out because that tool isn't cool anymore, and nobody wants to work with not-cool tools, and we've all got our resumes to worry about. I wonder if there are some cultural changes that could help mitigate this. If there really is an endorphin rush when working with a fancy new tool, why is that there and what can we do to replace that? Is it resume-building, is it enjoyment of that stage of knowing-nothing, is it happiness when you easily do that one thing that was annoying the shit out of you with the old tool? Can you pick apart why you were excited about and wanted to adopt Go?
• netvarun 7y ago
  Not having the site https-enabled is also a tenet of boring technology? /s
• matwood 7y ago
  > But anyway, despite that, I’m mostly not a tool-obsessed engineer. I didn't think there was many of us out there ;) I like cool new tools, but my obsession is solving the problem in the most effective manner. Too often I see people starting with the tool and then trying to shape the problem to fit the tool.
• oftenwrong 7y ago
  Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprised to discover that in the time since we’d launched it, the usage had increased by a factor of 20. And as far as I could tell it was totally fine. >The fact that 2,000% more people could be using activity feeds and we didn’t even have any idea that it was happening is certainly the greatest purely technical achievement of my career. I get a huge kick from making something, and then forgetting about it. For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well.
  • stinos 7y ago
    For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well. Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click of the button so to speak. That's just nice. Does make me wonder sometimes what exactly all other knowledge I gathered since then is good for. Some of it is definitely wasted on shiny stuff. But most of it is software architecture and with repect to the subject I'd translate that as 'how do I make this large scale application a combination of all those small and nice tools, and make that combination itself also work as those small nice tools'.
    • jasim 7y ago
      I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though! We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major change after the second year. This transiency of our work as programmers is something I am yet to come to terms with. I can't recollect where, but there was an interesting consolation in that while the code might be transient, the value created was real, and that's what matters. But the code is an artifact of our waking hours; it matters, like memories matter.
• dynamite-ready 7y ago
  This is an excellent article, but it's almost advocating a doctrine, when perhaps the best approach is to have no doctrine at all. I appreciate the idea of mastering a language or technology. It is often much easier than adopting something new. But the main reason for adopting something new, is to make doing something much easier. That 'something' is often a call to solve a new problem. I feel you generally come to understand why you should adopt a technology, after mastering your current set of tools. If we were to really take to this idea of maximising the tools that are already available, then we probably all still deploy applications over FTP. I think the two most valuable take-aways for me, are the importance of discussion, and the desire to have as small a number of dependencies as possible.
  • asdfman123 7y ago
    > when perhaps the best approach is to have no doctrine at all A general rule of thumb in life is you should follow rules until you understand when to break them, and despite the ageism in this industry I feel a decade under your belt of high quality experience really helps. KISS is a great general guideline .
• pqdbr 7y ago
  That's why I keep choosing Rails for my new projects. Boring as hell. Gets the job done.
• tracker1 7y ago
  I'm not sure I agree with some of the examples... For instance, since Redis can replace Memcached in addition to other chores, what would it have taken for a migration strategy to eliminate an older tech in favor of the newer one? In the end, I understand how each tech adds costs and values... however, one shouldn't be afraid to update/change things. It's too easy to be stuck on a decade and a half old tech if you are and don't at least try to keep up a little. Then the upgrade is exponentially more costly.
  • mu1313 7y ago
    I don’t think the point is not to migrate. The point is to discuss and make the decisions globally not at the whim of “this makes me happy” or “we have a new problem”.
• lvh 7y ago
  Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I think the problem/technology set illustration is particularly useful. I run Latacora's Cloud practice and we own all production infrastructure and "no, more boring, boringer than that, keep going" is a good way to describe what that looks like. We deploy half a dozen projects with exactly the same zero config storage and in ECS Fargate because I'm not managing servers.)
  • sydd 7y ago
    But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features
    • lvh 7y ago
      I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is. For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category). Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?
• sebringj 7y ago
  This so depends on the talent of your team. If you are normal then play it safe as most of us are. But if you want to make something great then you must resort to exploration, discovery and invention.
  • lvh 7y ago
    Part of the point of the article is that you probably don't need new technology to create a new _product_.
    • sebringj 7y ago
      Right, for an incremental product for sure. Slack is an incremental product but now is worth billions. Point taken but Slack is not SpaceX.
      • lvh 7y ago
        Your example of a sector where we can’t use conservative technology to make progress is space travel? ;-) But look, I see your point, but the “counterpoint” doesn’t actually disagree: the point is that a lot of incremental improvements in infrastructure feel transformative, but you get to pay the full cost regardless.
• brokenkebab 7y ago
  While I see the point, I also see that all "boring" technologies were new kids on the block at some moment, and often succeded at replacing previous "boring" thing. So maybe the proper advice should sound less absolute. Something like: Be cautious, and don't discard less exciting technologies, just because they are older.
  • phalangion 7y ago
    That's entirely the text of the article. But your headline is a lot less punchy than his.
• xwdv 7y ago
  There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to work on boring stuff that pays the bills, and who knows, if you are successful with a new technology early on, you might just be working on it for a very long time, continually breaking new grounds. Choose bold technology early, then boring.
  • shapiro92 7y ago
    So much this! I mean the author also worked for 7 years at Etsy which did ship quite a lot of new things (bad and good). For me this is similar to telling a 20 year old, dont go out, stay home, watch tv you will less likely get injured.
  • fogetti 7y ago
    The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.
    • bonoboTP 7y ago
      > The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization. Sure, if your interests are closely aligned with the company. But as you noted, the junior engineer jumped ships 3 times already, probably with significant salary increase each time, and in part due to a CV that includes the use of exciting modern tech, which shows he's eager to learn and is passionate etc. Why would he care how the old company is doing? People often don't stay at the same place long enough to feel the long-term consequences. People will do whatever the (job) market rewards and is fun. It's a bit different when you wear multiple hats. Then it may be best to focus on one specialization and keep things boring for the rest. For example at a small company, as a single-person data scientist/engineer/developer you may want to focus less on the IT fads and more on the modeling, because your CV is best padded by fancy new ML models, not by fancy new database engines. Or vice versa.
• apo 7y ago
  > 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. The presentation talks about "innovation" tokens. You only get so many to spend. There are also pain tokens. And you must spend a threshold of them to understand the quoted statement. It's not fun, but you will be enlightened.
• ravenstine 7y ago
  I choose boring technology because it less likely to waste my time. If I choose exciting technology, I will inevitably run into a cryptic error, even if I follow "Getting Started" perfectly, and it will be either difficult or impractical to resolve properly. That happens to me all the time, and I imagine it's due to insufficient testing and developers relying too heavily on their local environment. Better to work on something boring, but was carefully constructed over time and doesn't require 1/10 the dependencies of today's newfangled thing.
• liveoneggs 7y ago
  I proudly used "boring" to describe a massive simplification of my work's architecture that I have been working on for the last few years. It has been a successful culling of tech down to the bare minimum (as always- still a work in progress). Anyway my boss got so so offended and angry that I would use the word "boring". I spent the rest of the day trying to explain it and calm him down. Anyway use caution with the word "boring". It's more toxic than nuance would suggest.
  • jp_sc 7y ago
    I don't think the word is the toxic one in your story.
• parasubvert 7y ago
  A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology. This is a great presentation, and great advice. What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends. Most people orbiting IT wants to be a part of something that changes the world: it’s their ticket to higher paying job elsewhere, bragging rights at a conference, internet fame/notoriety via blog posts, etc. This is how we wind up with Service Mesh proxied MongoDB on Kubernetes as THE ANSWER, and all the ensuing political battles / turf wars to fight boring alternatives as “yesterday’s news”. It would be nice to see a greater focus on business outcomes, but I find few have the patience or bandwidth to truly track the success of a technology choice, unless you’re a larger company making a periodic cash bet with a business partner (eg software vendor). And even then, failure can be swept under the rug sometimes. It requires strong leadership and management (or a great culture) to encourage your teams to communicate tradeoffs and make these sorts of “boring tech” decisions without it being more about individuals playing a turf game.
  • chucky_z 7y ago
    I would like to throw my 2 cents in that some of these advances around "new" ways do lead to some good things. The focus on service discovery is something that is incredibly helpful even for older technologies. Consul is something you can add to even a very old application and give it modern scaling features, simply because it has a plain old DNS interface. Redis is similar for caching, it's advanced, the interface is so simple to use, and it's so easy to deploy and manage. On the flip side, I'd like to add that I worked for a startup and we chose a lot of boring technologies because we had a job to get done, and they all just worked. :)
  • hadsed 7y ago
    Not sure I agree with this perspective. Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them. In some cases they either see it not work many times or see a future where other organizations get to that point and need a better solution. In digging into what these companies do it becomes clear that they aren't doing it just to push new tech, but maybe I'm the one who hasn't seen enough. You mention k8s and related stuff isn't always the answer. Seems you think it's somewhat valuable? I'd like to hear what sort of tech you think is creating a bubble by being so useless! Certainly k8s can't be it, because for large companies the automation abilities of such a system are quite clear. Does it intro new problems, of course, and if they aren't well solved yet you'll have to think hard about the benefits of adopting The New Way, but to call this a bubble is hard to accept.
• shapiro92 7y ago
  Such strongly opinionated statements should be taken with caution. In our profession context is key and this theory does not always apply in every context. Imagine if the Netflix guys were told to stay boring and not invent new shiny things? Ofcourse not everyone is in that scale. I do not want to use the latest shiny tech but I do not want it to be boring as well. We are confusing KISS and boring here. A company I used to work at was running a job server at 90% utilization all the time and it even worked as a jump box, this is simple and boring but its also plain stupid. Invest some time and make it proper. Maybe when I am 50 years old I will want a boring setup, but until then no. I want to be engaged and active in what I do.
  • TsomArp 7y ago
    One thing is to "use boring technology" and a different thing is to "build boring products"... I can build shiny new things with boring technology.
    • shapiro92 7y ago
      by new shiny things in the netflix scope i meant like sidecars not the service itself
  • nemild 7y ago
    I would change that last phrase, "I want to be engaged and active in what I do" to "I want to build something that solves user needs and ships and is maintainable." Or at least a mix between the two.
    • shapiro92 7y ago
      I would not change it no. Let's say you are working on solving world hunger but you have to press 1 button every 24 seconds for 8 hours. Yes the goal is great, but I wouldnt be able to do it for more than a week. I need to be engaged and active in what I do 40 hours a week in which 40% is taken by the Gov as taxes.
  • mschuster91 7y ago
• nemild 7y ago
  An older piece that I loved is Dan's point on just allowing a certain number of technology tokens in any project: https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology I think one big part of the mistake is using Hacker News, Reddit, conferences as a sign of what companies are actually using. Instead, I liken it to a bazaar: https://www.nemil.com/on-software-engineering/beware-engineering-media.html https://www.nemil.com/on-software-engineering/beware-enginee... Oh, and remember marketing is not reality, even though marketers try awfully hard: https://www.nemil.com/mongo/3.html https://www.nemil.com/mongo/3.html
• sethc2 7y ago
  If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before. My hope is for those who agree with the author's premise, that it is still using the same "boring" technology and more people switch to it, because over the last two years when we switched to use Typescript, it has gotten significantly more valuable as more and more people have used it because now a majority of the dependencies I take on have type definitions provided via DefinitelyTyped, or are included with the package.
  • nemild 7y ago
    I would go for it, but just the fact that you're asking shows that you're less susceptible to injecting needless technology. Typescript has also been used for years, and it has a place as Javascript is used for more complex products than it was intended. I wrote a short bit in "Handling Hype" here arguing that you need to dig into your problem, assess claims, and weigh tradeoffs: https://www.nemil.com/mongo/1.html https://www.nemil.com/mongo/1.html
  • fnord77 7y ago
    See that slide that shows the bipartite graph of Problems on the left and Technology on the right. Typescript would be an extra edge in that graph and thus would impact the equation in the subsequent slides. So it would be a shiny new technology.
    • lvh 7y ago
      Can you elaborate? I don't quite understand. (I also think TypeScript is a great example of a category breaker here since it's a lot closer to a linter than a database. Sure, you have a new compiler stage so it's not quite free :-))
  • sudhirj 7y ago
    I’d say talk about it with the team, see there’s enough buy in from the existing team and enough awareness of the extra stuff to learn for both current and future team members. Then try it incrementally on some of the most hairy or type bug ridden parts of the codebase (so you can quickly prove utility) or on some smaller / newer parts of the code (so you can quickly prove compatibility). Then a wider rollout should build up its own momentum if it’s anywhere as helpful as you’re hoping it’s going to be.
• StreamBright 7y ago
  1 million times yes. We used to have a late adopter group in Amazon for people who do not get excited about new and shiny and keep on rolling with stable and battle tested tech.
• fnord77 7y ago
  This is great and I agree 100%. The problem we faced is hiring people. We found that in order to attract talent, we had to let them use the shiny new technology. Otherwise it would be hard to attract anyone.
  • lvh 7y ago
    I think the real punchline there is just "hiring is hard", because elsewhere in the comments someone has made the argument that you shouldn't use shiny technology because it's too hard to find people (specifically, you'd be screwed if that one person left). Maybe that's a company maturity thing: fancy tech is good for attracting talent early, boring tech is good for attracting a sufficiently large ops team later.
  • JustSomeNobody 7y ago
    I can see that. It's a shame though. Personally, I prefer to work on interesting projects. The tech stack used is an afterthought for me.
  • mratzloff 7y ago
    Yes, this is the one addendum to the presentation. An organization must periodically refresh itself in order to continue to attract talent. As an organization ages, it acquires more and more code to the point that rewriting becomes unfeasible except on epochal timescales. Thus some natural expansion becomes inevitable. The key is to contain this expansion.
• draw_down 7y ago
  Everything you think is boring was new at some point. Ultimately, shiny is what other people like, boring is what you like. What other people like is complicated, what you like is simple. Et cetera
• zzzcpan 7y ago
  > The failure modes of boring technology are well-understood Well-understood failure modes can't get you to resilience and are not all that well-understood to begin with. I guess it's just a false justification people use to stick to familiar broken old technology and broken ways or maybe to avoid relying on people with rare expertise, I don't know. If things were as simple as this we would just handle all the failure modes of "boring technology" in software and get perfectly working systems. But we can't, all the unknown unknowns and not understood failure modes are still there in boring technology, and reliability is a "do backups" afterthought. Systems really have to be designed for reliability if reliability is important and currently software reliability is too cutting edge to be boring.
  • nixpulvis 7y ago
    Depends what you mean... it is often easy to wrap fallible dependency calls with exception logic, and even workarounds sometimes, as long as the logic and failure are clear. It's mostly a matter of choosing boring software, because it's well documented, both in terms of (semi)-official docs, and things like SO answers, vs. newer software that might have modern advantages and also more undocumented or untested edge cases to be fixed.
  • JustSomeNobody 7y ago
    > I guess it's just a false justification people use to stick to familiar broken old technology and broken ways or maybe to avoid relying on people with rare expertise, I don't know. This sounds a bit nose in the air to me. > Systems really have to be designed for reliability if reliability is important and currently software reliability is too cutting edge to be boring. And yet, people have posted examples of "boring" software running for over a decade.
• pjmlp 7y ago
  Pretty much this, and if shinny technology is actually worthwhile it will stick around, and then it is time to bother learning it.
• fogetti 7y ago
  > "You can’t do poetry if you’re worried about what you’re going to eat today" Well let me just add this: > "Shortly after his release from the prison at Meung-sur-Loire he was arrested, in 1462, for robbery and detained at the Châtelet in Paris. He was freed on November 7 but was in prison the following year for his part in a brawl in the rue de la Parcheminerie. This time he was condemned to be pendu et etranglé (“hanged and strangled”). While under the sentence of death he wrote his superb “Ballade des pendus,” or “L’Épitaphe Villon”, in which he imagines himself hanging on the scaffold, his body rotting, and he makes a plea to God against the “justice” of men." - I wouldn't call that the highest step on the pyramid
• kabes 7y ago
  Somewhat playing devil's advocate, but if everyone joins that club, we keep the status quo and there's no more progress. If everyone joined this club in the 50's/60's we'd still be writing assembly. It's the guys pushing new shiny things that allows our domain to go forward, we just need to accept that 90% of the shiny new things eventually turn out to be crap. It's about the other 10%.
  • rektomatic 7y ago
    At the end of his shpeel he talks about how to adopt new technologies intelligently. He's not saying that no one ever should but that you need to go about it a certain way to reduce risk.
  • buboard 7y ago
    You can argue there has been a lot of progress in web development since 2000, and you can argue it hasn't. I think we did a lot of circles around ourselves, creating new frameworks that do the same stuff as the ones before them. The real progress was in browsers and CSS which allowed things like access to device cameras/inputs, rtc technologies and adaptible layouts.
  • closeparen 7y ago
    We are all writing assembly. There are just increasingly powerful levers between us and the assembly. That's why sticking with a technology for so long is powerful - the advances in tooling keep compounding. Imagine if we switched to a completely different paradigm every few years and had to start compiler research over from scratch.
• her_tummy_hurts 7y ago
  I was hoping for an article about choosing drilling equipment
• yepguy 7y ago
  Like many developers I have a strong desire to work with more exciting technology, even when there's no business case for it. Strangely enough, I've found the best outlet for that energy (other than personal projects when I get free time) is configuring Emacs. It's less disruptive than putting a new language or database into production, and makes me significantly more content to work with a boring stack. Plus I get a more comfortable computing environment out of it. Maybe someday I'll get Emacs just the way I like it, and need to find something else to distract me from chasing the new and shiny, but I kind of doubt it.
  • celeritascelery 7y ago
    I am the same way. I can tell when my main job gets boring because I start to tinker with emacs more and it provides that intellectual stimulus I need. Not to mention helping optimize away some of the more rote parts of my job.
  • redisman 7y ago
    I haven't used emacs so why is configuring it so interesting?
• Hoasi 7y ago
  Related: Lateral Thinking with Withered Technology https://en.wikipedia.org/wiki/Gunpei_Yokoi https://en.wikipedia.org/wiki/Gunpei_Yokoi
• dekhn 7y ago
  I wrote a MySQL/python sandwich ordering app 20 years ago. It's still in use- when they moved to a new site, they had to do a data update. I offered to rewrite using modern web tech but they said they were happy with it as it because it was boring and simple and got the job done.
• buboard 7y ago
  Yeah but its sometimes hard to figure out what are those boring technologies. What is a boring webrtc or websockets server for example?
• EMRZ 7y ago
  Solutions are like referees, good ones goes unnoticed, bad ones inspire hate.
• geophile 7y ago
  So many words. So few ideas.
• asdfman123 7y ago
  One step ahead of you! I'm a C# developer.
• vocatus_gate 7y ago
  Probably too late to contribute to the discussion, but I chose Windows Batch for the Tron project (https://old.reddit.com/r/TronScript https://old.reddit.com/r/TronScript) because it's super reliable and works on every version of Windows.
• stcredzero 7y ago
  During the 20th century, the Mig-21 was tried and true. It was rugged and dependable. One US test pilot described it as, "Fuel it up and go!" It would fit all the qualities of "boring" tech in this article. However, as a spectator, there's really nothing boring about it.
• vladsanchez 7y ago
  McFunley is awesome! Been an inspiration since "Choose Boring Technology" was released! It's a shame not many ppl follow his advice.
• mark_l_watson 7y ago
  Great points. I was reminded about a period of close to ten years when “my stack” was Apache Tomcat with servlets and JSP. I would handle background tasks in threads initialized in servlet init methods. For me it was a universal platform for anything I was required to develop and deploy. I was in Chicago last month and had breakfast with an old customer (I had never met him in person even though I did a ton of work for him between 2000 and 2006). One of my tasks for him was writing a Sharepoint clone that ran for five years totally unattended by his ops team. After five years they ran out of disk space and did a quick migration to a larger server. My customer thought that in five years they had never restarted to system or rebooted the server (yikes!, no security updates?).
• the_af 7y ago
  I wanted to disagree with this article, but it's all perfectly reasonable. It makes a lot of sense and it's well written. It's also not an absolutist viewpoint, which makes it even more reasonable. The danger I see here is that when the places I worked in chose "boring, well-tested" technologies they picked COBOL or ColdFusion. It's not true that I would be happy to ship software that worked if done using these tools. If I had to work with them again I'd shoot myself in the... face. I don't think I ever learned anything valuable from them, except maybe "sometimes the tasks you're given will be boring, and that's how life goes".
• mcguire 7y ago
  I am in complete agreement with this. (Sing it, brother!) But, "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 like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. [...] These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that." I don't buy this. If you try to save up your brainpower, innovation tokens, intellectual capital, or whatever, what you'll find when you come to try to use it is that you don't have it. Sort of like if you try to save up your upper body strength for a couple of years before you try to climb El Capitan. But I am just saying that is a poor example.
  • Balgair 7y ago
    The meme that you can 'save up' or 'train' your mental reserves has seen a bit of a come-back lately. However, the scientific evidence of such a thing is scant to none. In general, people that claim you can train your focus and eureka-moments are not looking at the evidence. Brett at AoM has a good intro article on it here: https://www.artofmanliness.com/articles/motivation-over-discipline/ https://www.artofmanliness.com/articles/motivation-over-disc... Tl;DR: Be disciplined, not motivated. Don't worry too much as well.
    • nafey 7y ago
      It is not just about saving "brain power". It is also about saving time.
  • redisman 7y ago
    The anecdote sounds like Andrew is trying to avoid decision fatigue which is somewhat related but not really what the author thinks it means.
• lordleft 7y ago
  "The long and short of it is that you have to talk to each other. Technology has global effects on your company, it isn’t something that should be left to individual engineers. You have to figure out a way to make adding technology a conversation. This might be underwhelming if you were expecting a big insightful secret here, but trust me, this is beyond many technology organizations." Well said. Also, clutch french revolution references.
• nine_k 7y ago
  (1) Discussion from 2015: https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 (2) «You can't pay people enough to carefully debug boring boilerplate code. I've tried.» (Yaron Minsky; via [1]). "Boring" is a wrong word, I think. Choose hassle-free technology that is known to work without surprises. Don't chose simplistic technology that produces busywork, even if it's rock-solid and bullet-proof. Choose a reliable technology that operates on the right level of abstraction, or closest to it. [1]: https://news.ycombinator.com/item?id=9161366#9161917 https://news.ycombinator.com/item?id=9161366#9161917
• aphextim 7y ago
  When reading the headline, I felt as if this was a logan/advertisement for Elon Musk's company.
  • 0027 7y ago
    Same. I blame it on the capitalization. "Choose boring technology" reads like a statement. "Choose Boring Technology" does not.
• switchbak 7y ago
  It's fun to dive in and "modernize all the things" - and certainly you can learn a lot in the process (perhaps at the expense of the business). I don't believe that the only reasonable alternative to that is to "choose boring tech" though. Like so many things in life, it's very contextual, and this is where you need someone with a lot of background and war wounds who can discern valuable improvements from yet-another-CADT-library-rewrite. Sometimes they're hard to differentiate from an old crusty cynic though. I'm resistant to either pole - I think there's often a 'middle way', where you can leverage proven, high-quality software (think PostgreSQL) while still benefiting from modern approaches (pragmatic functional idioms, etc). I'm old enough to remember when the industry was generally more entrenched in ossified approaches - it definitely has its downsides too! The hard part is when a (supposedly) proven technology turns out to be a turd. Much of the job of choosing good tech appears to be using heuristics to avoid low quality tech with good marketing. I'd love to have better tools to guide that problem!
• branevoid 7y ago
  Thanks for the advice dad! It all makes sense now!
• bpyne 7y ago
  I'm only part way through the presentation, but I loved this line. "And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is." Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby, or just veg out. Experimenting with new (to your organization) languages and infrastructure pieces is something you do between projects, not during. It reminds me of something a jazz musician said in an interview, "The audience doesn't pay to see you rehearse. Rehearsal is done on your own time away from audiences." Rehearsals are where you try new techniques, harmonies, instruments, etc.
  • 6chars 7y ago
    I'm uncomfortable with this rehearsal analogy. I'd rather have a company pay me to learn new things than spend my free time coding when I could be seeing my family, pursuing a hobby, or vegging out. From my employer's perspective, I agree that boring is usually better, but as an individual, I'd rather learn on the job than having to feel the need to "rehearse" for my job.
    • bpyne 7y ago
      I didn't mean no learning on the job. The time to learn is between projects. If your employer keeps people on projects constantly, then learning happens between tasks.
• mruts 7y ago
  If you want your business to succeed, you need to have multiple edges against the competition. Simply using what other people are using isn't going to give you a technological edge. Look at Paul Graham with Viaweb. He used lisp because it gave him a significant advantage against other players stuck with C++. Or Jane Street, started by three ex-Susquehanna guys using OCaml. There's a lot of technology that isn't boring that also isn't unstable either. These are technologies that probably should be more boring at this point (Common Lisp, Haskell, OCaml, Scala) but are rock solid and stable. These are the kind of technologies you should be using. On the otherhand, if all your "tech" start-up is doing is running a CRUD website, it probably doesn't matter what you're using.
• yellowapple 7y ago
  I agree pretty wholeheartedly with using tried-and-true tools instead of chasing the new shiny. I somewhat disagree, however, with the idea that a diversity of tools in use always necessarily leads to higher costs. Sure, using the right tool for each job increases the number of tools you have to maintain, but using the wrong tool for a job increases the maintenance costs of that tool while also introducing an opportunity cost from the resulting inefficiencies of using that tool for something it's not designed or optimized to do. As an analogy, you could use a screwdriver to turn screws or to pry something apart. Sure, this is cheaper than buying an actual prybar to use for prying, and you only have to have one tool in your toolbox instead of two, but this is a surefire way to break your screwdriver in a warranty-violating way.
• luizfelberti 7y ago
  I agree with this, but from a different angle, and possibly different reasons. I don't think we should use boring tech for sake of it. I think we should use boring ideas, and sometimes boring ideas come in new packaging that brings better tooling and community support to the table. Single server architecture, relational databases, are an idea. Postgres is an implementation of such idea. What we understand about the failure modes of something like Postgres, are not actually specific to Postgres, but to the ideas behind it dating back to Codd himself, and most other databases that came along the way. Same thing can be said from DBs that derived from the BigTable paper (Cassandra, Scylla, etc). Of course they have specific operational differences, but they have at least twice as much common ground. The way we understand the failure modes of these projects, is by looking at the ideas behind it (Gossip, Paxos, AP, SSTables, LSM-Trees). We understand things by stripping away their specifics, and seeing how their core ideas interact with each other. The specifics of each solution are merely tie breakers. This is why I would never call something like Clojure or Elixir "shiny new hype technology". Clojure is nothing but a modern implementation, backed by an excellent community, of mature ideas that have stood the test of time. Lisp itself is as old as the dinosaurs, and functional programming is not as new as people think. It has just been "rediscovered" recently, once the hype/aversion passed and we were able to look at it with sober eyes. Elixir is also a modern implementation, with better tooling/community, of things that have been in BEAM for 20+ years. Apache's Samza/Storm for stateful stream processing are reimplementations of things the Erlang community has been able to do with Mnesia since at least 1999. It's also something we sometimes circumvent by using things like Redis to deal with stateful computations, and Google recently seems to have realized this and published a recent paper, trying to go back to that old idea[1]. In short, I think it's a really good thing that we have new tech that tries to make the old ideas better, and I generally feel pretty safe experimenting with those. You just have to learn to recognize these values, and adequately investigate solution candidates before jumping into what could very well be just hyped up crap, because sometimes, it isn't. [1] https://ai.google/research/pubs/pub48030 https://ai.google/research/pubs/pub48030 discussion https://news.ycombinator.com/item?id=19823022 https://news.ycombinator.com/item?id=19823022
• ncmncm 7y ago
  Whenever somebody brings up this "unknown unknowns" thing, I'm reminded again why we ended up in such a shitstorm in Iraq: Rumsfeld listed three out of the four possible combinations of "known" and "unknown" that he had his minions thinking about for him. But, evidently, neither he nor his minions thought of or spent any time on the fourth one: unknown knowns. Those are the ones you think you know, but you're wrong. And that's what knawed 5 trillion dollars out of our guts (and killed hundreds of thousands of men, women, and children) over the next N years since. It is not a new observation. Usually Mark Twain gets credit for "It ain't what you don't know that gets you, it's what you think you know but ain't so."
• mkr-hn 7y 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 do something similar, but in a way that keeps it interesting. I always pull a shirt off the right and move the hanger to the left for clean ones out of the dryer. Pants are the same. Stacked stuff always comes off the top. Clean ones go on the bottom. I also went with Blogger in 2019 rather than fuss over blog engines. It's exportable, free, runs under your own domain, has few restrictions on front-end customization, and is unlikely to go out without warning. At worst, I defer thinking about it until later when I have a better sense of my needs. Related to that, I started on a PHP-based static blog engine. I reasoned that PHP was made for smushing data and HTML together, so it was perfect! https://github.com/CondensedBrain/blogengine https://github.com/CondensedBrain/blogengine But I also saw a future where I had to maintain all the bits and pieces. I really just wanted a blog, not a blogging engine. I hadn't read Choose Boring Technology yet, but it affirms the thinking that led me to pick Blogger over a custom engine and other pre-made options.
• dnautics 7y ago
  what if the shiny new technology is optimized for lower maintenance cost relative to older technology?
• Rafuino 7y ago
  Working on new hardware technology, it's really interesting for me to think about OP's call to only use "proven technology," but how do you get a technology to the proven state if everyone is only using previously proven technology? You can force it if you control a platform (e.g. stuff wireless hotspots everywhere and have wifi capability attached to new laptops), but that's pretty rare in hardware. https://www.siliconvalleywatcher.com/intels-centrino-and-how-it-sparked-the-wifi-hotspot-revolution/ https://www.siliconvalleywatcher.com/intels-centrino-and-how...
• Mugwort 7y ago
  This is one of my favourite tech talks ever. So very, very true. I agree with everything he says. On the other hand, writing software the same way without changing is hard to do and there is the temptation to try something new for the sake of trying something new. It's very strong with me and I've learned to indulge my urge to play with shiny new toys in a way that doesn't blow the main project to kingdom come. I need to write something that will go nowhere just to get it out of my system.
• RickJWagner 7y ago
  Nice, but too long. I'd hate to sit through all of it.
• lacampbell 7y ago
  I think it's much more important to choose a minimal set of technologies, than to choose ones that are boring. If one 'shiny new' tech can replace two boring ones, I am first aboard that hype train.
• mschuster91 7y ago
  One thing I don't see mentioned is: why are people not honest with themselves? We're using hyper-scalable databases, "serverless", layers upon layers of caching, microservices with dozens upon dozens of interconnects, all built out from the start for the odd chance that the thing we build will be the next unicorn startup. But what is the reality? Many fail before the tech stack ever becomes a bottleneck and those who do not fail rarely reach the scale that requires the absurdities we use today. A good old LAMP stack on a decent dedicated server is, honestly, way more than enough for 99.9% of startups and doesn't need highly expensive dedicated AWS and other specialists to get up and running in nearly no time.
• unstatusthequo 7y ago
  Wow so serious the comments in this thread. I immediate thought of the Boring Company and how they want to un-fuck traffic in ways that governments can't. Then I got let down a lot. Boring.
• cottsak 7y ago
  This will be largely lost on most practitioners of software delivery... Unfortunately.
• mnajiri 7y ago
  أفضل المواقع العربية لمشاهدة وتحميل المسلسلات والافلام https://mdwab.blogspot.com/2019/05/Best-site-films-Series.html https://mdwab.blogspot.com/2019/05/Best-site-films-Series.ht...
• AtlasBarfed 7y ago
  ... wait, is MongoDB considered a boring technology? ... but Cassandra is "shiny"?
• morenoh149 7y ago
  This is why I stick with Django, DRF, Postgres, Reactjs, linux vms and REST over HTTP. Once the business problems are solved we can try out new tech. With this stack I've built many web apps and there are fewer surprises.
• kyle-rb 7y ago
  >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. I think I'm the opposite way. I tend to like technologies when I know all the quirks, e.g. CSS: "Well of course you have to make the parent element positioned in order to get the child's absolute positioning to work, how else would you do it?"
• sjun 7y ago
  There's a big movement in the Web community to move everything to JavaScript. Js on the server side with Node, html generated by Javascript, and the latest trend CSS-in-js. On one hand, this can be argued as centralizing on one technology that will reduce long term cost because the operational stack around it can be reused: tests, build tools, deployment. However it very much can be seen as adding another technology to manage since it's adding a shiny new library to maintain with all the bugs and kinks along the way.
• gabaug 7y ago
  Dan's “re-use the technologies you already have deployed instead of adding redundant technologies” point is what resonates most with me. > The interesting thing here is that none of the tools that you pick may be the “right tool” for any given job. But they can still be the right choice for the total set of jobs. Even if that "one choice" isn't totally boring, at least you only have one thing to figure out all the kinks of and support.
• vlindos 7y ago
  One of the best articles have seen recently!