When seeking to determine the success of any business activity, measurement of productivity is one of the very first things that managers reach for. The impulse behind this is understandable. By reducing complex processes to a set of numbers, we are in a better position to get a handle on what is being achieved. There is a problem, however. Some activities are much more suited to being measured than others. For example, it is quite easy to measure how many widgets you produce in a certain period. When it comes to something like software development, things become much more complex. This is where application modernization strategies, including IBM i monitoring, can prove very useful.
The purpose of this article is to survey the field of software productivity measuring. This will be done by finding answers to some key questions. Towards the end the focus will shift to how application modernization strategies, including IBM i monitoring, can help companies in this vital area.
What Do We Mean by ‘Software Engineering Productivity’?
This is a question that is not as simple as it may appear. It is easy to become fixated on a specific metric (e.g., lines of code, or revenue earned) as a means of defining productivity. However, things are much more complex than that. To get a fully rounded picture of productivity the following questions will have to be asked:
- How are developers performing? In other words, are they delivering reliable products, of high quality, that are free of bugs or other problems?
- In what ways are developer activities benefiting the company? Here the focus will be on factors like customer satisfaction, the reduction of cost and the raising of the company profile through the deployment of well-regarded and reliable products.
- Which outputs or actions are in evidence? This question deals with the most directly measurable aspects of the work of developers. Things that might be measured in this area include lines of code, build counts, frequency of deployment, code reviews, incident mitigation statistics etc.
- Are developers effectively collaborating and communicating with each other? We obviously do not only want to be measuring individual outputs, but also whether the synergies available through effective teamwork are being achieved.
- Is work being done efficiently and in a timely manner? In any business situation a balance will have to be struck between how fast work is done and the quality of outputs. This question seeks to determine whether this is done in an optimal manner.
- Are developers being well cared-for? Employee satisfaction and well-being is key to long-term business success. Determining whether developers are generally content and well supported in their roles should, therefore, also be part of the productivity picture.
Get insider tips on how LANSA’s low-code platform can help your organization utilize IBM trends in modern-day software development and digital transformation.
Why Should Companies Measure Software Engineering Productivity?
The adage ‘What gets measured, gets done’ certainly applies to software development. This is not an area where we can simply hope for the best. Making sure that inputs (in terms of developer time and effort) match output should go without saying. Measurement will, furthermore, show up in the areas where bottlenecks occur. This can then lead to focused interventions so that processes and efforts can be streamlined and coordinated. It is, lastly, the case that time is money. Measurement is, therefore, also essential to ensure a healthy bottom line. Specifically in terms of ensuring that your company gains a solid return on investment on the cost of engaging developers. It should be noted that IBM i monitoring can be helpful in achieving this aim.
What are Some Examples of Software Engineering Metrics?
It should come as no surprise that a vast range of metrics have been developed over the years. Here are some of the most important ones for individual developers:
- Number of commits – Measures the number of commits made to a file
- Average commit size – Goes beyond the raw numbers of commits to measure the scope of changes to a file
- Time to review – Measures responsiveness to the need for work on a file
- Number of code reviews – A key metric to determine how effective and ‘clean’ code is
- Frequency of code reviews – Like the above, but with a focus on how often remedial action is needed.
In addition to these measures, that can be applied to individual developers, attention should also be paid to team performance. In this space, the focus should be placed on the rate at which teams produce useful and well-functioning software. Financial metrics, (e.g., total spend vs. revenue earned) can also be more successfully applied at a team level.
Why are Attempts to Measure Software Engineering Output Sometimes So Painful?
As human beings we are very prone to try and reach for ‘magic bullets’ when seeking to solve a problem. However, we invariably must face up to the fact that reality is a bit more complex than we expected. This is certainly true when it comes to measuring productivity in software development. Despite the abundance of metrics, there is simply no one size fits all solution. The main reason for this is that counting the number of actions (e.g., lines of code) is not at all the same as counting the value of those actions. Some developers can deliver superior software with far fewer lines of code than used in the output of their less efficient competitors. There is, furthermore, the perennial problem that just about any measuring system can be ‘gamed’. In other words, some developers will focus so much on the specific action that is being measured that their work will suffer in other areas.
How Can we Identify the Right Software Engineering Productivity Metrics?
Because of the factors mentioned above, many managers prefer metrics that are focused far more on ultimate outcomes than on processes. In other words, we need to be primarily focused on issues like return on investment, customer satisfaction and developer wellbeing. In other words, we should do our best to make the best use of the valuable time of developers (and to gain a good return on investment from it) and to also promote their wellbeing as much as possible. The reality is that developers who have appropriate tools, work under clear expectations, and are fulfilled in their work will be more productive. Any metrics that we develop should be in the service of these objectives, otherwise we can very easily get lost in pointless bean counting exercises.
Learn about the valuable insights gathered from the POWERUp 2021 sessions — one of the IBM conferences 2021 held by COMMON.
How can LANSA help to Promote Software Engineering Productivity?
As mentioned above, an obsessive focus on counting lines of code is probably not the best way to improve productivity. Instead, ways have to be found to improve outputs in a cost-effective way. Ideally any solutions should also contribute to developer wellbeing. While there are obviously many answers to how these objectives can be achieved, here at LANSA we are convinced that IBM i modernization and monitoring can be a part of the solution. Modernization of legacy applications means that much more attention can be paid to achieving outcomes than on working with complex code. Take a look at our low-code solutions to see how this can be done. Our solutions also include monitoring tools, so that the process of measuring productivity can be automated and designed to focus on the right metrics. In short, if you would like to see productivity improve, you have to check out LANSA’s suite of solutions for IBM i modernization.
