Assessment denotes the process of understanding a given situation about a software system 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. In this talk, we argue that we need to:
• Make assessment 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 assessment. 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 ourselves. 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.