Assessment challenge & promise

Traditionally, when we say software engineering we primarily refer to the process through which we build software systems. It's the construction part that captures all the spotlight. However, several studies report software engineers spending as much as 50% of the development effort on assessing the current state of the system from various points of view.

In other words, assessment accounts for half of the budget allocated for building the software system. These are just the direct costs. The indirect costs of this activity can be seen in the quality of decisions made during development.

All these qualify assessment to be a critical activity. However, in practice, assessment is regarded as secondary. While for the process of building the system we have a large body of strong engineering know-how (e.g., patterns, practices, technologies), when it comes to assessment we find mostly ad-hoc solutions. This does not service.

Assessment must be recognized explicitly and approached as a distinct discipline. It is too important to do otherwise. Only by making it explicit can it be optimized.

Software systems are complex and present many contextual problems. To be effective, assessment must be tailored to deal with the context of the system and of the problem at hand.

The ability to assess a situation is a skill. Like any skill, it needs to and can be educated.

Mastering the analysis technology is an issue but it is not the key one. We do need a dedicated technology, such as Moose, that provides the ability to craft tools fast. But, a tool that checks software is software as well, and software engineers already know how to produce software. The main challenge is to shift the focus of engineers from what to develop, to how to check what to develop.

The challenge is significant because it requires a paradigm shift. But, it comes with the promise of the costs that can be decreased when going from ad-hoc to structured.

And, the best news is that the budget is already allocated. Implicitly, but allocated. And developers already spend it. It just takes the energy and will to do it differently.