Uncertainty - Enemy No. 1 of High Longterm Productivity

If clean code development is about high longterm productivity for teams, then the natural first question is: What's impeding teams to be continuously productive?

Customer facing productivity means producing value at a desirable rate. It does not mean delivering just anything, but what is useful and to the point from the perspective of the customer.

Effort is invested into code, e.g. 2 hours or 4 days or 6 weeks, the resulting software is presented to the customer - then the customer is the judge over how valuable the perceived change is. However: Even if all developers are exhausted after this effort, but the customer is not satisfied, the team hasn't been very productive from the customer's point of view.

That means: Effort invested into results not deemed valuable is (at least partly) a waste.

But why is there a risk at all, the customer might not accept a piece of software as valuable after all the effort? Uncertainty!

Photo by Roma Kaiuk on Unsplash

There is a lot of uncertainty in the requirements which teams are trying to convert into code. It's hidden in all steps of the transformation process of requirements into code:

• It's uncertain if the customer knows what would be valuable to his users of the software.

• It's uncertain if the customer explains the requirements clearly with regard to his understanding.

• It's uncertain if developer understand the explanations of the customer.

• It's uncertain if the developers transform requirements true to their understanding.

• It's uncertain that even high quality code with regard to the customer's explanations will satisfy him in the end, because in the meantime his situation might have changed.

Uncertainty is lurking everywhere in software development. And that means waste is likely to be created as long as the uncertainty bull is not taken by the horns. 

Uncertainty must not be a surprise.

Productivity is an inverse function of uncertainty. As long as uncertainty is surprisingly high, productivity will be low. Not only in the long run, but also short term productivity.

The first measure to be taken for clean code development thus has not to do with code, but the environment, the atmosphere code is produced in. Uncertainty has to be embraced! It needs to be understood that uncertainty is inevitable on many levels. Change will be inevitable. A customer not accepting a presented solution as valuable must not be a surprise.

Agility with its iterative-incremental approach to software production is the foundation of clean code development.

Clean code is produced in "thin slices" to avoid larger deviations from what in the end is valuable to the customer.

From uncertainty follows that software very fundamentally is preliminary. Code thus should not be prematurely fixed:

• Prototypes avoid casting requirements into production code as long as there is still a high level of uncertainty.

• Explicitly modelling a solution avoids writing production code while there is high uncertainty regarding the approach to solving a problem.

• TDD as if you meant it avoids writing production code to satisfy a certain requirement as long as there is still considerable uncertainty regarding the required logic.

• Microservice or component architectures avoid fusing all logic into one monolith to be able to answer longterm uncertainty with partial rewrites.

Uncertainty is the first enemy of longterm productivity to be tackled. Without coming to terms with uncertainty and preliminarity teams will waste time in detours and code will be loaded with waste products of failed attempts.