Delivering Software Value to your Business: Users per Line of Code

If you work inside a SAAS company objectively determining the value of your software and developer hours may not be easy, but it is certainly less difficult then determining the value of a internal business application. How important is this feature? Is it worth the level of effort in developer hours? Agile attempts to address these questions with story points effort points, but this metric is often hard to communicate to management and does not facilitate the justification of lowering technical debt.

The metric I am putting forward is Users per Line of code (Users/LOC). This is calculated by taking the users of an application and dividing it by all the lines of code that go into making a deployable binary, including files that do not compile such as configurations or stored procedures. This can give a team a rough estimate of their application's value to the business.

When multiple applications share code between them through a shared DLL or other means that do not involve manual copy and paste, the shared code's total lines can be divided by the number of applications sharing it. Conversely, if a team is trying to calculate their application suite's total value they can sum all of their applications' lines of code while only adding the shared code once.

The reason that lines of code factor in to this metric is because by only looking at an application's  total users no value is placed on a developer's time or productivity. Although, life seldom has absolutes, having less lines of code generally makes a modification of an existing feature easier. Additionally, if an application's architecture is conducive to code sharing adding a requested feature will not as negatively effect the lines of code. As far as bugs go, there is a direct relationship between an application's lines of code and the number of bugs that will occur.

I am not proposing Users/LOC as The One True Metric™, but rather an additional metric in the application developer's tool box. Focusing on any one metric can incentivize destructive behavior in any organization. Obviously, Users/LOC must be used in conjunction with other metrics; overemphasis may incentivize poorly readable code.  If your company's CEO is the primary user of Reporting Application X, obviously Users/LOC is not the most appropriate metric.

It is easy to imagine Users/LOC being used as a component of another metric; for example in an agile environment, (Story Points * Users) / LOC. Users/LOC can also be used on a feature basis as opposed to being used for an entire application for enhanced accuracy. There is high value in this metric because it can reduce both over-engineered code and under-engineered code. If Application A is used by one person to simply do basic data entry to one table with minimal validation rules is over-engineered with a 5-layered web service architecture an extremely poor Users/LOC score will result. If application B has the same complex business logic that must be repeated on five different pages but the developer under-engineers by not isolating the business logic in its own layer this metric's score will also be lower than expected.

In summary, Users/LOC can help lead developers and product managers increase their value to the business by both helping to direct resources appropriately and detecting poor architectural and allocation decisions after the fact. More users, more impact and visibility. Less lines of code, more impact potential per developer hour in the future. Maximize users per line of code and maximize your application suite's short-term and long-term value.