7 ms·

> There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. https:/

> There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

exdsq 5y ago
Thanks, this is the one! Highly recommend it, especially when you're in the HN echo chamber of new and interesting technologies
- gurjeet 5y ago
  See also: http://boringtechnology.club/ http://boringtechnology.club/
- amarshall 5y ago
  Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.
  - eximius 5y ago
    That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".
    - beermonster 5y ago
      Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.
      - rgoulter 5y ago
        Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.
        eitland 5y ago
        > It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the cli.) 2. and to just stick to the basics. (And when you need to help someone else who didn't, take it carefully even if that means you don't look like a wizard.) In fact even working on the command line feels easier once I had worked in a good gui for a while. Don't believe experts who claim that you need to study vim and stick to the git cli to "get it". But of course: if cli is your thing, use it, just stop writing blog posts that claiming it is the only true way.
        carlmr 5y ago
        Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.
        copperx 5y ago
        Magit is the most recommended one. But it comes with an Emacs dependency.
      - amarshall 5y ago
        The latter. As a (bad) analogy: it’s a bit like learning Haskell. If you’ve only ever worked in strictly-evaluated, imperative languages, it’s not gonna be easy to learn. Nevertheless, Haskell predates e.g. Go by two decades. Nix (and Haskell) has its warts, and undoubtedly a new system would avoid them (compatibility needs make some changes very challenging), but the fundamental difficulty remains because it is fundamentally different and solving a truly difficult problem set.
    - KronisLV 5y ago
      > That is extremely concerning, then, that it is so difficult to use after all that time. > I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years". I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even though you sometimes are forced to install proprietary ones for optimal experience, should get better in the next decade). So, might have to wait for a bunch more years, or just pick something else, like OpenBSD, or just run in a set of constraints for having a really predictable and well supported hardware configuration, which isn't always possible. Alas, my off brand Polish netbook will just have to wait before i can (hopefully) run BSD on it comfortably. Well, short of making the missing pieces of puzzle myself, for which i'd probably also need a decade or so of systems level development experience, as opposed to just web dev and occasionally dabbling in lower level stuff to mediocre success. Of course, by then the netbook itself might not be relevant, so who knows. I also feel much the same way about GNU/Hurd - a project that is conceptually interesting, but isn't yet quite stable, even though apparently you can get Debian for it: https://www.gnu.org/software/hurd/ https://www.gnu.org/software/hurd/ Now, i don't have almost any experience with it, apart from reading about it, but some people tried figuring out when it could be released based on the bug reports and how quickly they were being addressed, and the number that they came up with was around 2070 or so. In summary, there are probably projects out there, for which their age isn't necessarily related to how usable they are, whereas other pieces of software will have never truly achieved that stability in the first place. Not all old software is good (edit: at least not for certain use cases). Of course, there are exceptions, for example, you can look at Apache2/httpd: it is regarded as old and dated for the most part, however just recently an update was released, which added mod_md. It now lets you get Let's Encrypt certificates without external tools (like Certbot), in some ways setting it ahead of Nginx: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html Not all old software is always boring. Same for Docker and any other tools. If developers use tool A for use case X, instead of tool B, then maybe there are some very good reasons for this widespread usage? That's also probably the answer to this debate - regardless of their conceptual/technical benefits, the usability will probably decide which tool will win in the long term.
      - 5y ago
  - exdsq 5y ago
    Huh, cool! This is like Python being older than Java :mindblown:. Still, old technologies can be just as risky as new ones.
  - roguas 5y ago
    Nix popularity is still lower than Docker, even during dotcloud era(I think this was the og company). Boring means common, unnuanced, rather than older or first.
laumars 5y ago
I hadn’t seen that before but it perfectly sums up my approach to tech. I’m going to share this the next time someone questions why I take a pragmatic approach rather than jumping on the next new tech stack Thanks for sharing
Cthulhu_ 5y ago
I wish I had seen that (and fully understood the implications) years ago, I mean it's been in the back of my head all the time but never explained this well. I've referenced it a couple of times now, especially the slides showing the graphs of technologies and links which is a really succinct way of saying "adding one technology multiplies complexity".
kwertyoowiyop 5y ago
Strangely, once a team adds one risk, they feel more comfortable adding a second risk. Ditto for the third risk, etc. The psychology is weird.

exdsq 5y ago

Thanks, this is the one! Highly recommend it, especially when you're in the HN echo chamber of new and interesting technologies

gurjeet 5y ago
See also: http://boringtechnology.club/ http://boringtechnology.club/
amarshall 5y ago
Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.
- eximius 5y ago
  That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".
  - beermonster 5y ago
    Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.
    - rgoulter 5y ago
      Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.
      - eitland 5y ago
        > It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the cli.) 2. and to just stick to the basics. (And when you need to help someone else who didn't, take it carefully even if that means you don't look like a wizard.) In fact even working on the command line feels easier once I had worked in a good gui for a while. Don't believe experts who claim that you need to study vim and stick to the git cli to "get it". But of course: if cli is your thing, use it, just stop writing blog posts that claiming it is the only true way.
        carlmr 5y ago
        Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.
        copperx 5y ago
        Magit is the most recommended one. But it comes with an Emacs dependency.
    - amarshall 5y ago
      The latter. As a (bad) analogy: it’s a bit like learning Haskell. If you’ve only ever worked in strictly-evaluated, imperative languages, it’s not gonna be easy to learn. Nevertheless, Haskell predates e.g. Go by two decades. Nix (and Haskell) has its warts, and undoubtedly a new system would avoid them (compatibility needs make some changes very challenging), but the fundamental difficulty remains because it is fundamentally different and solving a truly difficult problem set.
  - KronisLV 5y ago
    > That is extremely concerning, then, that it is so difficult to use after all that time. > I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years". I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even though you sometimes are forced to install proprietary ones for optimal experience, should get better in the next decade). So, might have to wait for a bunch more years, or just pick something else, like OpenBSD, or just run in a set of constraints for having a really predictable and well supported hardware configuration, which isn't always possible. Alas, my off brand Polish netbook will just have to wait before i can (hopefully) run BSD on it comfortably. Well, short of making the missing pieces of puzzle myself, for which i'd probably also need a decade or so of systems level development experience, as opposed to just web dev and occasionally dabbling in lower level stuff to mediocre success. Of course, by then the netbook itself might not be relevant, so who knows. I also feel much the same way about GNU/Hurd - a project that is conceptually interesting, but isn't yet quite stable, even though apparently you can get Debian for it: https://www.gnu.org/software/hurd/ https://www.gnu.org/software/hurd/ Now, i don't have almost any experience with it, apart from reading about it, but some people tried figuring out when it could be released based on the bug reports and how quickly they were being addressed, and the number that they came up with was around 2070 or so. In summary, there are probably projects out there, for which their age isn't necessarily related to how usable they are, whereas other pieces of software will have never truly achieved that stability in the first place. Not all old software is good (edit: at least not for certain use cases). Of course, there are exceptions, for example, you can look at Apache2/httpd: it is regarded as old and dated for the most part, however just recently an update was released, which added mod_md. It now lets you get Let's Encrypt certificates without external tools (like Certbot), in some ways setting it ahead of Nginx: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html Not all old software is always boring. Same for Docker and any other tools. If developers use tool A for use case X, instead of tool B, then maybe there are some very good reasons for this widespread usage? That's also probably the answer to this debate - regardless of their conceptual/technical benefits, the usability will probably decide which tool will win in the long term.
    - 5y ago
- exdsq 5y ago
  Huh, cool! This is like Python being older than Java :mindblown:. Still, old technologies can be just as risky as new ones.
- roguas 5y ago
  Nix popularity is still lower than Docker, even during dotcloud era(I think this was the og company). Boring means common, unnuanced, rather than older or first.

laumars 5y ago

I hadn’t seen that before but it perfectly sums up my approach to tech. I’m going to share this the next time someone questions why I take a pragmatic approach rather than jumping on the next new tech stack Thanks for sharing

Cthulhu_ 5y ago

I wish I had seen that (and fully understood the implications) years ago, I mean it's been in the back of my head all the time but never explained this well. I've referenced it a couple of times now, especially the slides showing the graphs of technologies and links which is a really succinct way of saying "adding one technology multiplies complexity".

kwertyoowiyop 5y ago

Strangely, once a team adds one risk, they feel more comfortable adding a second risk. Ditto for the third risk, etc. The psychology is weird.