7 ms·

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,

by 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!
    - manojlds 10y ago
      Been using Terraform in anger, and I agree with your statement. It is not for everyone, not yet anyway, but I love using it. Btw, Terraform 0.7 comes with initial support for import and state manipulation commands.
- jwr 10y ago
  > > tools that change their behavior based on files in one of the parent directories > You mean like git? In case of interactive tools like git it is something you would expect. But it came to me as a rather huge surprise that if you type "npm install" in a directory where you just unpacked sources, what will actually happen depends on what exists in the PARENT directory. Not to mention writing to the parent directory. I am not alone in being caught off-guard by this: https://github.com/npm/npm/issues/2896 https://github.com/npm/npm/issues/2896 I'd say this is unacceptable in case of tools that are "make-like".
  - qaq 10y ago
    what's make like about a package manager?
    - IncRnd 10y ago
      Do you really think that npm doesn't build software using dependency management?
      - qaq 10y ago
        It sure does "build software" but it's primary function is package management. We could call Emacs an email client by the same token. An equivalent of make in js world are Gulp, Grunt etc.
  - hugozap 10y ago
    It's an npm convention according to the dependency resolution algorithm, not a flaw. If you have a .git folder in the parent directory you also get different/possibly unexpected behavior. It's not unacceptable if you have read how it works. Both cases are documented.
  - rhinoceraptor 10y ago
    That seems pretty normal, if I'm in a subdirectory of my project and install a dependency, it makes sense that it would install it in the root of my project where the node_modules/ folder is. When I use git in a subdirectory of my project, it looks for .git/ up the directory tree until it finds it.
- liveoneggs 10y ago
  I really want to use terraform but after dealing with the collection of hacks called vagrant I am not so excited to do so. (speaking of randomly merging up parent directories)
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.

by jwr 10y ago

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!
  - manojlds 10y ago
    Been using Terraform in anger, and I agree with your statement. It is not for everyone, not yet anyway, but I love using it. Btw, Terraform 0.7 comes with initial support for import and state manipulation commands.
jwr 10y ago
> > tools that change their behavior based on files in one of the parent directories > You mean like git? In case of interactive tools like git it is something you would expect. But it came to me as a rather huge surprise that if you type "npm install" in a directory where you just unpacked sources, what will actually happen depends on what exists in the PARENT directory. Not to mention writing to the parent directory. I am not alone in being caught off-guard by this: https://github.com/npm/npm/issues/2896 https://github.com/npm/npm/issues/2896 I'd say this is unacceptable in case of tools that are "make-like".
- qaq 10y ago
  what's make like about a package manager?
  - IncRnd 10y ago
    Do you really think that npm doesn't build software using dependency management?
    - qaq 10y ago
      It sure does "build software" but it's primary function is package management. We could call Emacs an email client by the same token. An equivalent of make in js world are Gulp, Grunt etc.
- hugozap 10y ago
  It's an npm convention according to the dependency resolution algorithm, not a flaw. If you have a .git folder in the parent directory you also get different/possibly unexpected behavior. It's not unacceptable if you have read how it works. Both cases are documented.
- rhinoceraptor 10y ago
  That seems pretty normal, if I'm in a subdirectory of my project and install a dependency, it makes sense that it would install it in the root of my project where the node_modules/ folder is. When I use git in a subdirectory of my project, it looks for .git/ up the directory tree until it finds it.
liveoneggs 10y ago
I really want to use terraform but after dealing with the collection of hacks called vagrant I am not so excited to do so. (speaking of randomly merging up parent directories)

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.