Programming is a Flow of Decisions

Whether good or bad, timely taken or missed depends on the professional level of software engineer dealing with your product.

Programming is a flow of decisions. Global, big and small. It is like we deliver useful meaningful flow of thought when we speak or write prose. In fact it is like how we live our lives.

We make decisions based on the values and patterns we were brought up with. We use approaches we learnt before. Our life becomes the result of our decisions. We live consciously or not, intentionally or accidental, well or poor.

The software product - its core deliverable producing consumer value - code - is the same result of thousands decisions developers (in a broad meaning from architects to beginner developers) make. But unlike life, where the set of decisions and consequences varies unexpectedly, in programming the list of decisions is determined as are the consequences.

The issue with programming though is that the number of decisions professional engineers make for commercial product starts somewhere at 2,000. Even the most basic decisions on how to write code ¹ account for a few hundred.

Need to say the absence of the right decisions does not mean the absence of decisions. Quite contrary. The unintended mostly wrong decisions will follow leading to defective consequences.

Seemingly Effortless Mastery

Another important analogy clarifies this otherwise undetectable phenomenon. Professionals writing code are like top musicians playing highly complex musical pieces. Both seemingly effortlessly combine thousands of decisions into a beautiful piece of work within seconds.

But with music, most of us immediately ² will hear the professional level of the musician. Is it really a master, or just a beginner? Is the performance sloppy or masterful?

Unlike in programming, where the unintended, alien decisions in batches silently pass uncaught by businesses who pay to developers for some initial months of product development.

The Consequences

These decisions consequences become visible much later in the project. But the cause-effect connection is so subtle that only professional engineers and experienced business people in digital product development can discern the root causes.

Nevertheless the cause-effects are visible, stark, and predictable enough to be described here.

One team arrives, promising to quickly build some calling "MVP" (note it is not certainly minimal, neither valuable, nor even finished product). As the codebase grows, the "quick" becomes its opposite until the code full of accidental decisions cannot anymore accept changes the team is asked to make. At that point the code becomes a throwaway. As a result of the team's occasional code decisions. The team leaves and the other one comes.

If by chance the team is at nearly the same professional level, they claim to do it well. As they proceed they gradually understand the code is throwaway and sooner or later go away leaving the code the same or more throwaway than before.

At this stage, the business hopefully recognizes the difference between professional programmers and those who pretend to be. But probably it is broke by now.

There are a few interesting notes upon this story:

• the story ends with no viable product;
• the deliverables - discernable knowledge about the product domain - are non-existent (neither explored, nor documented, nor clearly modeled in code);
• the investment is wasted;
• the business experience is earned overly expensive way;