It may not be the envisioned futuristic age of robots and flying cars just yet, but one cannot argue against the fact that technology has indeed created a neat space for itself, one that cannot be overlooked. Software has devoured every industrial space to the extent that software and business today go hand in hand. This backbone of large and small organizations alike is created by rigorous, diligent and creative development. Companies invest a fair proportion of their resources to the expensive staff that drive the development of technology on which an organization runs. It is therefore imperative to explore and quantitatively measure the performance of such investments by empowering teams with the ability to track their efficiency. This task is delegated to a designated software development manager.
So how can a software development manager measure the productivity of his team? How is a manager expected to measure without a metric?
This article discusses a few metrics and determines if they serve as means by which software development managers can confidently make decisions regarding the most effective way to deliver projects.
- Counting Lines of Code:
Can we associate quality of a developer with the number of lines of code contributed? While greater contribution does evaluate to more work it does not necessarily, attribute better quality of work. We cannot assume that a developer that has contributed greater volume of code is working efficiently. The objective is to achieve functionality with minimum possible code. Hence, while lines of code indicate consistency and work progress, it is not an efficient metric to evaluate productivity. This leads us to the next point, where functionality is key.
- Function Points:
Functionality seems like the pivotal purpose to write code and a function point represents a step towards achieving the desired functionality. Can we monitor user functionality developed and delivered by the developer to evaluate performance? There are also several task-tracking tools such as Bugzilla and JIRA widely used that eradicate the manual effort of administrating progress. So can we not count the number function points completed using these tools? Well, the issue here stems from the dynamic nature of each function. Each function is different. While some may be pretty straightforward, others require greater effort and time. While a function in one programming languages may be easy to accomplish, it may be more challenging given another language. Thus, a developer having completed greater function points cannot be weighed above other members of the team. Moreover, such a metric would hamper teamwork as a developer could easily cherry pick simply achievable function points. So this does not serve as a reliable metric of judgement.
- Story Points:
Similar to function points, story points are often used during the stages of software development. Frequently adopted in agile methodology, a story represents a business requirement of the project. Depending on the amount of work, complexity, risk and uncertainty of the task at hand, the effort required is calculated and accordingly a size is assigned to each user story. This size represents the number of story points. Burn down charts are often used to estimate the story points’ progress. Here, a measure of the coding effort is the unifying factor; yet again this metric presents a fallacy, as the initial estimation of the size assigned is left to the manager’s discretion. For example, a story point that should be 2 may have been inaccurately measured as 4 and hence developed slowly. So can the developer be given greater credit for the task accomplishment? This metric provides a suitable measure to determine work progress but not work efficiency. Measuring the coding effort seems like the right track to arrive at a reliable metric, but manually estimating the size of story points makes this metric undependable.
- Coding Effort:
As discussed in the previous point, measuring the coding effort seems like the way to go to assess work progress but not work productivity as it is often falsely estimated which results in inaccurate size of story points. There is a need to better estimate the coding effort required and tools such as blue optima have been designed for this purpose. The tool measures the developer’s rate by analyzing the coding effort between code commits. It then gives a measure of cost per unit time. A ratio of cost per hour to coding effort per hour gives a cost per coding effort ratio that provides valuable insight into a team’s efficiency. By analyzing this metric, organizations can gain intelligence about the actual coding effort required for various function or story points, which will allow manager’s to better estimate the size of story points and competently deliver projects.
Software project delivery encounters numerous hindrances and challenges at the enterprise level due to the scale of projects, dependencies, risks and time bound requirements. Organizations must do their best to ensure that projects are delivered smoothly to minimize business impact and it is the duty of the software development manager to safeguard the development train as it runs on its rails. By identifying suitable metrics, a guide to cost effective and reliable delivery can be achieved,