The IT crowd, entropy killers

I once asked myself "how to define our job in the most general sense of the term, we, computer scientists ?".

Our fields are very diverse but according to me, the greatest common divisor is "entropy hunter".

All we do have is geared toward the same goal : decrease the level of complexity of a system by modeling it and transforming a bunch of semi-subjective rule into a Turing machine program that can't execute the indecisive.

Everything we do, including documentations, workshops with the stakeholders, project aspects, and not only the programming activities should be about chasing doubt. Every word, every single line of code should kill ambiguity.

Take design activities : most of human thoughts are fuzzy. This is the reason why waterfall (traditional) project management processes where all designs are done in one go can't work : the humans need to see something to project themselves using it and go further in their understanding.

Business designs are subjective in many ways, for instance :

• by describing missing cases (or less often, unexisting cases)
• by words ambiguity. Here's a small anecdote : last week, I worked on a specification document written in French with the word : "soit" : "the file contains two kinds of data, soit data1 and data2". This sentence could be understood in two opposite ways because the French word "soit" means "either/or" but also "i.e.". Hence, this sentence could mean at the same time "the file contains data1 AND data2 kinds" or "the file contains data1 OR data2 types". I encounter this kind of uncertainty several times a week.
• by lacking of examples. The example are often much more demanding and objectionable. They require a better understanding of the system. Moreover, designing by the example (like in BDD) tend to be more complete because when you start to provide nominal examples, you are tempted to provide the corner case ones. (read BDD in Action by John Ferguson Smart for more).

On the opposite, a program is deterministic. It is a more formal (and modeled thus reduced) version of a complex reality. The more a reality need cases and rules to be described entirely, the more the program is complex but it is still much simpler than the reality it describes.

The quality of all we do should IMO be measured in the light of the amount of complexity we put into our programs. The less complexity we used to model a system, the better a program is.