Warnings are design errors

Schattian — Sun, 27 Oct 2019 12:50:26 +0000

What an opinionated sentence.

Lemme explain: when I was starting, as the majority of us (I believe) I was obsessive to not have warnings on my dependencies/tools/whatever.

Acquiring experience, and looking at the very big systems, warnings are everywhere. Tons of them, on every: docker build, CLI tool, CI pipeline, etc.

I was thinking a lot about how that can be real, with those "potential errors" everywhere, at every time, and all of the developers not paying attention to these but trying at the same time to test the best way they can to be near zero errors in the runtime.

Or the warnings aren't really "potential errors", or all the devs out there are badass (like those my code is always great).

Then, and googling about logging, I saw one post with a near POV, coming from the excellent Dave Cheney blog, in which he said:

... "Nobody needs a warning log. Setting the level to warning is an admission that you’re probably logging errors at warning level." ...

So there I started to see with a bit more hateful those logging levels.

From then, and when I was working with 3rd party software, I was trying to see why the dev which created that piece includes that log at that level.

For example, in the past week, I implemented the ELK stack (ElasticSearch, Logstash, Kibana), together with Filebeat and Redis, to centralize and visualize logs ~~isn't that irony?~~.

Then, I received the first warning:

2019-10-20T06:52:15.316-0700 WARN beater/filebeat.go:152 Filebeat is unable to load the Ingest Node pipelines for the configured modules because the Elasticsearch output is not configured/enabled. If you have already loaded the Ingest Node pipelines or are using Logstash pipelines, you can ignore this warning.

Note: Yes, I was using Logstash pipelines.

Another example is the typical hardware related warnings, like
You are at 98% of RAM usage or similar.

What does make the number 98 that special? You don't know if I want to use just half of the memory to have the capability to scale the execution or sth else... That's an INFO log.

Or the typical Ruby on Rails warning warning: already initialized constant X.

It is a constant? It was initialized two times? Constants are constant, not runtime-only constant. It is an error.

So, basically, those says: "maybe you are wrong or maybe not. If not, ignore me".
This means: "I think you are probably not smart enough to use my software."

But I'm not saying that all the warnings are done by people who think they're smarter than the rest. No.

Remembering a general design principle "easy to use and hard to misuse", I think this problem came when the software you are building is not simple enough, or the API it uses isn't clear.

From the ambiguous parameters in the config to the very well-known nullable-only-if-you-know-what-you-are-doing.

Then was when I realized that every warning is a design error.

Don't misunderstand me: design errors are always unwanted but that's the real world, and sometimes you have a schedule (or even simpler, you are lacking ideas to do it in another way) and a design error is the easiest/fastest ~not the only~ way to proceed.

For me, warnings are to logging what dynamic typing is to type systems. When you're using them, you feel that this isn't the best way to do it, but it allows you to skip tons of rules and just do things work.

DEV Community: Schattian

Warnings are design errors