I work with some providers who sometimes call me when one of their customers has a problem with an application.

What is the first question you ask in a meeting with a customer?

• Which technologies in your application ?
• Is it a big application ?
• Is this application complex ?

No. I see that every time. And this is a natural reaction: first, qualify the application. Sure, you want to know if you can adress the needs of this customer. Sure, your partner looks to evaluate what could be the size of a possible deal. Continue reading →

Back to raw metrics.

A customer wants you to audit the quality of an application or a portfolio of applications. He expects for an answer to a very precise question. For example:

• This application is an important part of my budget: is it possible to reduce its costs and how?
• I have been asekd to take the maintenance of this application. I only know that it is a complex application. What do I have to expect?
• Is it possible to outsource this application? What are the risks?
• We are going to merge with this entity. What systems should we use? Theirs or ours?

There are two different questions in these questions:

• What are the costs?
• What are the risks? Continue reading →

In the previous post Measure and Control, I said that quantitative metrics such as the number of lines of code (LOC) or the measure of cyclomatic complexity (CC) were:

• easily available – in every software of code analysis ;
• exact – these measures do not vary (too much) depending of these tools ;
• easily understandable for the management.

Does this mean that qualitative measures would be difficult, inaccurate and poorly useful? In fact, everything depends of what you want to do, thus of the use case. Today, let’s see an ideal use case: Continuous Improvement. Continue reading →

« You can’t control what you can’t measure » (Tom de Marco)

I explained in the previous post The 3 costs that code analysis tools provided us a large number of qualitative information while quantitative metrics were less numerous, but very useful. This opinion is not always shared.

Raw metrics are easy to obtain with the great majority of code analysis tools. Generally, such a tool begins by presenting a global quality note which aggregates various rules of good practices of programming, design, documentation, etc. This simple note gives a general overview of the quality of the application, but is in fact rather subjective: it depends very strongly on the tool. Continue reading →

If you had to invest in a company, how would you make a decision?

There are 3 different ways to estimate the quality of a company or an organization.

The financial evaluation is the simplest because it is based on easily available data: revenue, profits, expenses, etc. On the other hand, this estimation is not the most relevant or the most precise: you know that company A and company B generate a 10 millions revenue and a profit of 1 million. It is thus possible that these two companies are very similar or, in any case, we have no elements to think differently.

The quantitative measures allow us to improve the quality of our evaluation. If you know that company A makes its revenue with 10 deals of 1 million while company B gets the same result with 100 000 sales of 100 (€ or $, does not matter), then you can already imagine that these two companies are not similar, sell different products and probably by different channels. If we add that company A is profitable on half of its sales and slightly loses on the other half, while company B is profitable on 90 % of its sales (but with a lower margin), the picture depicted by these data clears up. On the other hand, this evaluation is more difficult to conduct because this information is rarer and more difficult to obtain. Continue reading →