Software assessment: the elephant in the development room

What is assessment? I define it as the process of understanding a given situation to support decision making.

During software development, engineers spend as much as 50% of the overall effort on doing precisely that: they try to understand the current status of the system to know what to do next. In other words, assessing the current system accounts for half of the development budget. These are just the direct costs. The indirect costs can be seen in the quality of the decisions made as a result.

One might think that an activity that has such a large economical impact would be a topic of high debate and improvement. Instead, it is typically treated like the proverbial elephant in the room.

What can you do about it?

  • Make it explicit. Ignoring it won’t make it go away. By acknowledging its existence you have a chance of learning from past experiences and of optimizing your approach.
  • Tailor it. Currently, developers try to assess the system by reading the source code. This is highly ineffective in many situations, and it simply does not scale to the size of the modern systems. You need tools, but not any tools. Your system is special and your most important problems will be special as well. That is why generic tools that produce nice looking reports won’t make a difference. You need smart tools that are tailored to your needs.
  • Educate it. The ability to assess is a skill. Like any skill, it needs to be educated. Enterprises need to understand that they need to allocate the budget for those custom tools, and engineers need to understand that it is within their reach to build them. It’s not rocket science. It just requires a different focus.

All in all, assessment is a discipline. More information about my view on assessment can be found on the official site of the humane assessment method — a method that offers a practical approach to software assessment.

The presentation comes with plenty of examples and it is dedicated to both managers and engineers. Why both? Because the problem is both economical and technical. Managers have to understand the technical challenges that consume the budget silently. And engineers have to understand the economics involved in assessment.