Hacker News Reader

Comment by valarauca1 | Hacker News Reader

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.

View on HN

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.

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.

What issues do you have with Terraform? A few people in my org are considering implementing it.

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.

That's interesting. These guys tend to have pretty good luck with it - https://segment.com/blog/the-segment-aws-stack/

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

I'll keep that in mind. Thanks!

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.

Thanks for posting this. So it sounds like the main source of frustration is really just the state file? Is that accurate? I have heard this from someone else.

Also you mentioned that Terraform was better than the alternatives. Could I ask what other alternatives you looked at and why you ended up choosing Terraform over them?

The reason I ask is that I am also considering Terraform. However other providers also seem to support more than just AWS and are fast enough.

> and a lot more workable than the alternatives

That is pretty much it right there.

I've yet to see another solution that beats it. Warts and all, it's the best I've seen.

The syntax abstraction of cloud formation alone is worth using terraform for me. The state file I delegate to tearing the infrastructure down. No more.

Use the AWS API and your config management API ( chef ) to manage the state of the systems.

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

I'd say this is unacceptable in case of tools that are "make-like".

what's make like about a package manager?

Do you really think that npm doesn't build software using dependency management?

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.

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.

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.

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)

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.

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

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.

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.

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)

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

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.

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

One of the customers I was dealing with recently still requires .NET 4.0 due to XP support.

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

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.

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.

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.

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.

No doubt. I've even encountered somebody who stomped his feet and said they weren't going to write test code for QA because that was beneath them.

I think that's because the entire industry devalues both QA/testing and maintenance. Even in places that aren't the Valley these two roles are given a lower social status than other developer roles. The budgets and recognition for teams in both domains is typically much smaller than others, and QA especially is usually among the first on the chopping block during a retrenchment.

We as a whole have made these roles seem less valuable and less values, so to me it's not surprising that folks don't want to do them.

It really depends on personal traits. At our company we keep weekly training sessions to align everyone to have some minimal breadth.

Reply on news.ycombinator.com