Good Configuration Feedback Is Essential | Hacker News Reader

Good Configuration Feedback Is Essential

rigsomelight.com

34 pointsbrucehauman10 comments

The Spring framework is a good (or bad) example of this tension at work in Javaland.

If you did not use Spring, you'd have to invent your own configuration file format for your application. You'd work hard at it, wind up with something crappy, and you'd have to mess around with configuration system code whenever you change the system.

On the other hand, Spring exposes a huge amount of complexity to the end users and the error messages can be hard to understand. My experience is that if you read the Spring manual from cover to cover a few hundred times it will make sense, but if you try to learn "How to do X?" from Stackoverflow and Google you'll be driven crazy and if you have to deal with Spring files written by people who cut-and-pasted, you might be driven all the way to suicide.

Then there are all the apps like Jetty and Solr that have something similar built in but worse...

Great piece. What this means for me is how important it is to have a low latency feedback cycle. Even a cryptic error message, if it's immediate, will let me quickly try enough things to find the correct approach.

One of the most frustrating weeks I've spent was modifying bash scripts to work around wonky functionality on AWS Elastic Beanstalk. Every time I tried something, I had to wait 30 minutes for it to deploy and then examine the error message to see what was wrong.

Of course, in the meantime I would get distracted by something else, so the cycle time was even longer.

insert saying about how configuration is just programming but worse in every way

In the example, I'm not sure npm can really do much to fix this. package.json entries can have any arbitrary content. "dependncies" might be valid as far as npm knows, and the dependencies section is optional.

Maybe that's the problem? The file format is too loose and it shouldn't allow arbitrary content anywhere.

This seems like a situation where npm can't win. If it only allows npm-specific information in the package.json, then people will complain about how they have to have 10 different configuration files in the root of a JavaScript project. If they allow arbitrary configuration, it's blamed for being too permissive.

There are other possibilities. They could have a registry for allowed keys, or allow them but only under "extensions".

Even so, your error parser could examine common layouts, and figure out that while depndencies could be correct, it probably was meant to be dependencies.

While true, it would seem appropriate to inform a user that they tried to run `npm install` with no arguments and with no dependencies in their package.json.

Oh, a programmer had a problem with configuration of software. All of a sudden it is important to have validation and good error messages.

Ask some operations people about this, they have been dealing with this avoidable laziness for some time.

Reply on news.ycombinator.com