This is a response article for the blog post “SOFTWARE METRICS, ADVANTAGE OR DISADVANTAGE”. It could be found here:
In this blog post i am responding to an article about Software Metrics. My main point is: the author of the post said in the introduction that he will talk about measures from the client’s overview and then spoke about some traditional measures that are not even useful for people in the development team.
2. In response to the blog post
Software Metrics are important measures and they should be studied from two perspectives: people-inside the company viewpoint and clients viewpoint. We have seen in SAPM lectures that it is hard to estimate and measure software but we have to do something!
2.1. I got excited about this topic…BUT!
The blog post is started with a very interesting and thrilling point and I will put the exact sentence that took my eye: “Nowadays, customers need to know that what they are buying has the quality they need, otherwise they cannot use it and they will not buy it”. The author also stated a very nice example about buying a car. I was totally excited assuming that he will talk about software measures in the eye of customers. However, he continued his blog post stating the measures that MIGHT mean something for the software development team or manager BUT ,surely, not for the customer. The author mentioned a list of measures such as Lines of code, Number of classes & interfaces, Code to comment ratio, Code coverage…etc.
2.2. so what’s my problem with this blog post?!
The problem is that, all of these measures mean NOTHING to the customer. How in the world will a client decide whether a 4500-line-of-code is good or bad software?! Just imagine some client asking about your program and its quality and you tell him “Well, I have a 3500 lines-of-code in my program so it is amazing!”. It is not even useful for comparing! Who said that a 4000 line-of-code program is better than a 3000 line-of-code one?
2.3. COBRA Effect!
Further to that, these measures are really not useful neither for the manager of the team nor for the programmers themselves (recall. Lectures of Allan and Cobra effect…etc). If these measures are of NO USE neither for the manager nor for the programmers, how come will they be useful for the client? The same thing holds true for other measures you stated.
2.4. Successful Software Projects
Let me go to one of another colleague’s post “Easy facts about LOC used in software measurement” (https://blog.inf.ed.ac.uk/sapm/2014/02/11/easy-facts-about-loc-used-in-software-measurement) and take the following: “Clients care about the function. Only the business value brought by these function is meaningful. LOC is not a metric that could be used to evaluate how meaningful the function is. More code does not necessarily suggest that the function is robust or the business value is large”. This is exactly the case. Clients care about what your software will give them whether it has 100 classes or 1000 classes or even 1 class!
Clients might be more interested in the main criteria for successful projects. They want the software to be done on time, within budget and meet their needs in scope and quality. In case you want to tell your customers how good/bad you are doing in the project up to now, you should look for an easy-to-interpret and meaningful functional measures for clients. The client is interested in knowing how reliable my software is, how secure, and how efficient it is.
My point towards this blog post is that, in the introduction it gives me a feeling that it will provide us with measures from the viewpoint of clients, but then it goes into the traditional measures.
Taking into account all what I have just said, I am a 100% agreeing with the author that telling the client about our software is a real need whether as estimates, measurements when we are coding, or as an evaluation after finishing the Software. Speaking in terms of Reliability, Security, Efficiency, Maintainability might be more useful and easier to understand for the client.