8 ms·

Makes sense. Since the late 90's early 00's when Linux won the data center. Most people became really enjoyed the we don't break user land motto. Once a kerne

Makes sense. Since the late 90's early 00's when Linux won the data center. Most people became really enjoyed the we don't break user land motto. Once a kernel interface went live, it stayed that way. Ugly spots and all. Containers are starting to become a fairly important part of IT/Cloud infrastructure. Easily compariable to the OS itself. Logically those involved with maintainence would demand the same. Yes I'm aware Docker is more a control program for interacting with Cgroups, setting quotas, installing packages, and isolating processes. Not the OS itself. It is an abstraction over the OS, hence for most developers it feels like part of the OS. So logically they'd demand it be as robust as the OS.

jwr 10y ago
I think this is part of a more general trend of companies trying to use software that definitely isn't ready for prime time. Sure, it's trendy and being hyped, but those are not sufficient reasons to use it in production. These days some new technologies become "trendy" (on HN and elsewhere) and start being used by developers. That in itself is great, but many of those developers are also young and inexperienced and do not realize that production systems have different requirements. There are many symptoms: the docker situation, npm (need I say more), libraries like Semantic UI that can't be built in a CI environment from the command line (require user interaction). Even small things, like tools that change their behavior based on files in one of the parent directories (npm again, but not only), or the proliferation of fancy progress bars and useless drivel being spewed to the terminals, are symptoms. Those are tools designed by developers working on their laptops, for developers working on their laptops, and do not (at this stage) fit the requirements of a production server environment. Maturity and stability are valuable traits in software, especially in larger systems.
- scrollaway 10y ago
  The one that springs to mind for me is terraform. We made the decision to use it in production and it is costing us a lot of time and money. It feels like it will continue costing us a lot of time and money for a long time. It 100% feels like alpha software, yet it's being hyped and overhyped by the tech community. I personally think using it was the right call regardless (the alternatives are worse in the long run), but it's such a massive upfront investment, I couldn't recommend it. One thing though: > tools that change their behavior based on files in one of the parent directories You mean like git? I agree with your general sentiment but you're backing it up very weakly, with essentially irrelevant things. Terminal interactivity is not a bad thing; TUI software is built for humans as well as machines and well behaved components will detect when they are not in a tty.
  - iamthemuffinman 10y ago
    What issues do you have with Terraform? A few people in my org are considering implementing it.
    - scrollaway 10y ago
      Oh where to start... The state file is atrocious, a constant source of pain. It is hard to set up in the first place, it is hard to import resources into it, it is hard to rename resources within it. Sometimes, resources don't canonicalize correctly and will always tell you there's something to modify, even though there isn't. Other times, resources don't destroy properly because you are using some untested settings within them. "It's alpha software" is the best description I can give. It has a ton of rough edges. The pros: It's decently fast, and a lot more workable than the alternatives (cloudformation or simply tracking stuff by hand). It supports more than just AWS, including fairly obscure stuff like Cloudflare DNS records. It's conceptually solid. Don't say no to it outright, but you should know what you are getting into.
      - iamthemuffinman 10y ago
        That's interesting. These guys tend to have pretty good luck with it - https://segment.com/blog/the-segment-aws-stack/ https://segment.com/blog/the-segment-aws-stack/
        scrollaway 10y ago
        Seen the article before. It's not wrong - Terraform is pretty great. But it's leaving out the parts where a lot of stuff breaks, behaves in unexpected ways, is missing critical features etc. A lot of engineering time has to be dedicated to terraform if you're going to use it in a serious stack (and it's overkill as just a toy).
        iamthemuffinman 10y ago
        I'll keep that in mind. Thanks!
- k__ 10y ago
  But most software is promoted as "Production Ready" to these companies, because their producers need "Rapid Growth"-TM. If this went bad, you see something like MongoDB happen.
  - creshal 10y ago
    > If this went bad, you see something like MongoDB happen. What did we see? There's still buttloads of software being written whose authors flat out refuse to support a sane database.
- pjmlp 10y ago
  That is actually what I like about being a senior developer on enterprise consultancy. We see these fads come and go, wait for the dust to settle and use what is actually mature to be deployed in real production environment. It also helps that our customers don't sell software, as such they view of what technology stack is supposed to look like is quite different from what the typical Starbucks developer thinks about software.
  - dangerlibrary 10y ago
    I understand that you are probably referring to developers who work in a Starbucks, not for them. But I found your comment funny because Starbucks is one of our clients and our stack is exclusively mature, production ready technology.
  - hugozap 10y ago
    Just finished my Espresso Macchiato. I'm now waiting for it to influence my views on software,(jk it's funny the correlation between workplace/lifestyle preferences and software quality)
  - vetinari 10y ago
    Well, these customers are extreme in the other direction... JBoss 4 on Windows 2003? What could possibly go wrong, it has been working fine for years...
    - pjmlp 10y ago
      Personally not so far, but Java 1.4, Websphere 6, JSF 2.0, .NET 4.0, XP support still are quite actual subjects. But it surely is more fun than arguing what are this month JavaScript best practices and frameworks. Been there and don't miss it.
  - valarauca1 10y ago
    >It also helps that our customers don't sell software, as such they view of what technology stack is supposed to look like is quite different from what the typical Starbucks developer thinks about software. Selling software to people who use software vs those who develop software is a vastly different experience. As are the questions and rigor they'll put a consultancy agency though. As well as what they expect out of a product. >We see these fads come and go, wait for the dust to settle and use what is actually mature to be deployed in real production environment. Yup nothing like Oracle SQL + Java App driven by Tomcat or Spring. Hell you can even get an Oracle Rep to appear in your sales pitch. The suits really like that.
- JustSomeNobody 10y ago
  Definitely seeing a lot more of this type attitude in the industry: "You old developers just don't get it! The young are building the future! We LIVE on the bleeding edge, man. Who cares if there's a few bugs, that's what you MAINTENANCE developers do, fix the bugs that are beneath me. Besides, I'm out in like six months anyway. On to my next gig."
  - sidlls 10y ago
    I find it refreshing, as a near-40 year old who's been in the industry for over 10 years, that there is finally movement against the absurd notion that one must spend more than a couple of years at most (or all) their jobs in order to be taken seriously. There are two extremes. The one you point out leads to developers with lots of breadth and no depth. But the other is still the industry standard today: one that values depth in a particular (and possibly completely irrelevant outside of the company) domain. I hope we keep moving towards the middle of the two.
    - JustSomeNobody 10y ago
      And I would love to see the "developers" who stomp their foot and say they're not going to fix bugs because that's maintenance shown the door. Yes, this happens and yes it is very immature.
      - TheAceOfHearts 10y ago
        Presumably you'd want to strike a balance. I know I'd find a job rather dull if all I were doing was fixing bugs. Fixing bugs is very important, but I don't think it's unreasonable to ask for a a reasonably diverse workload.
        JustSomeNobody 10y ago
        Which is what I'm talking about. These people only want to write "new" code. Only. They don't want to fix ANY bugs. It's "beneath" them.

jwr 10y ago

I think this is part of a more general trend of companies trying to use software that definitely isn't ready for prime time. Sure, it's trendy and being hyped, but those are not sufficient reasons to use it in production. These days some new technologies become "trendy" (on HN and elsewhere) and start being used by developers. That in itself is great, but many of those developers are also young and inexperienced and do not realize that production systems have different requirements. There are many symptoms: the docker situation, npm (need I say more), libraries like Semantic UI that can't be built in a CI environment from the command line (require user interaction). Even small things, like tools that change their behavior based on files in one of the parent directories (npm again, but not only), or the proliferation of fancy progress bars and useless drivel being spewed to the terminals, are symptoms. Those are tools designed by developers working on their laptops, for developers working on their laptops, and do not (at this stage) fit the requirements of a production server environment. Maturity and stability are valuable traits in software, especially in larger systems.

scrollaway 10y ago
The one that springs to mind for me is terraform. We made the decision to use it in production and it is costing us a lot of time and money. It feels like it will continue costing us a lot of time and money for a long time. It 100% feels like alpha software, yet it's being hyped and overhyped by the tech community. I personally think using it was the right call regardless (the alternatives are worse in the long run), but it's such a massive upfront investment, I couldn't recommend it. One thing though: > tools that change their behavior based on files in one of the parent directories You mean like git? I agree with your general sentiment but you're backing it up very weakly, with essentially irrelevant things. Terminal interactivity is not a bad thing; TUI software is built for humans as well as machines and well behaved components will detect when they are not in a tty.
- iamthemuffinman 10y ago
  What issues do you have with Terraform? A few people in my org are considering implementing it.
  - scrollaway 10y ago
    Oh where to start... The state file is atrocious, a constant source of pain. It is hard to set up in the first place, it is hard to import resources into it, it is hard to rename resources within it. Sometimes, resources don't canonicalize correctly and will always tell you there's something to modify, even though there isn't. Other times, resources don't destroy properly because you are using some untested settings within them. "It's alpha software" is the best description I can give. It has a ton of rough edges. The pros: It's decently fast, and a lot more workable than the alternatives (cloudformation or simply tracking stuff by hand). It supports more than just AWS, including fairly obscure stuff like Cloudflare DNS records. It's conceptually solid. Don't say no to it outright, but you should know what you are getting into.
    - iamthemuffinman 10y ago
      That's interesting. These guys tend to have pretty good luck with it - https://segment.com/blog/the-segment-aws-stack/ https://segment.com/blog/the-segment-aws-stack/
      - scrollaway 10y ago
        Seen the article before. It's not wrong - Terraform is pretty great. But it's leaving out the parts where a lot of stuff breaks, behaves in unexpected ways, is missing critical features etc. A lot of engineering time has to be dedicated to terraform if you're going to use it in a serious stack (and it's overkill as just a toy).
        iamthemuffinman 10y ago
        I'll keep that in mind. Thanks!
k__ 10y ago
But most software is promoted as "Production Ready" to these companies, because their producers need "Rapid Growth"-TM. If this went bad, you see something like MongoDB happen.
- creshal 10y ago
  > If this went bad, you see something like MongoDB happen. What did we see? There's still buttloads of software being written whose authors flat out refuse to support a sane database.
pjmlp 10y ago
That is actually what I like about being a senior developer on enterprise consultancy. We see these fads come and go, wait for the dust to settle and use what is actually mature to be deployed in real production environment. It also helps that our customers don't sell software, as such they view of what technology stack is supposed to look like is quite different from what the typical Starbucks developer thinks about software.
- dangerlibrary 10y ago
  I understand that you are probably referring to developers who work in a Starbucks, not for them. But I found your comment funny because Starbucks is one of our clients and our stack is exclusively mature, production ready technology.
- hugozap 10y ago
  Just finished my Espresso Macchiato. I'm now waiting for it to influence my views on software,(jk it's funny the correlation between workplace/lifestyle preferences and software quality)
- vetinari 10y ago
  Well, these customers are extreme in the other direction... JBoss 4 on Windows 2003? What could possibly go wrong, it has been working fine for years...
  - pjmlp 10y ago
    Personally not so far, but Java 1.4, Websphere 6, JSF 2.0, .NET 4.0, XP support still are quite actual subjects. But it surely is more fun than arguing what are this month JavaScript best practices and frameworks. Been there and don't miss it.
- valarauca1 10y ago
  >It also helps that our customers don't sell software, as such they view of what technology stack is supposed to look like is quite different from what the typical Starbucks developer thinks about software. Selling software to people who use software vs those who develop software is a vastly different experience. As are the questions and rigor they'll put a consultancy agency though. As well as what they expect out of a product. >We see these fads come and go, wait for the dust to settle and use what is actually mature to be deployed in real production environment. Yup nothing like Oracle SQL + Java App driven by Tomcat or Spring. Hell you can even get an Oracle Rep to appear in your sales pitch. The suits really like that.
JustSomeNobody 10y ago
Definitely seeing a lot more of this type attitude in the industry: "You old developers just don't get it! The young are building the future! We LIVE on the bleeding edge, man. Who cares if there's a few bugs, that's what you MAINTENANCE developers do, fix the bugs that are beneath me. Besides, I'm out in like six months anyway. On to my next gig."
- sidlls 10y ago
  I find it refreshing, as a near-40 year old who's been in the industry for over 10 years, that there is finally movement against the absurd notion that one must spend more than a couple of years at most (or all) their jobs in order to be taken seriously. There are two extremes. The one you point out leads to developers with lots of breadth and no depth. But the other is still the industry standard today: one that values depth in a particular (and possibly completely irrelevant outside of the company) domain. I hope we keep moving towards the middle of the two.
  - JustSomeNobody 10y ago
    And I would love to see the "developers" who stomp their foot and say they're not going to fix bugs because that's maintenance shown the door. Yes, this happens and yes it is very immature.
    - TheAceOfHearts 10y ago
      Presumably you'd want to strike a balance. I know I'd find a job rather dull if all I were doing was fixing bugs. Fixing bugs is very important, but I don't think it's unreasonable to ask for a a reasonably diverse workload.
      - JustSomeNobody 10y ago
        Which is what I'm talking about. These people only want to write "new" code. Only. They don't want to fix ANY bugs. It's "beneath" them.