More is Less - Lines of Code, Project Complexity and Business Value
Monday, March 15, 2010 at 21:46 Recently Joannes made an overview of the projects composing public and private codebase of Lokad SaS, checking out their complexity and number of total lines of code (LOC) in each.
There were quite a few of these projects, ranging from the open source cloud mapper for the Azure and up to a number of quickly implemented and deployed tactical applications.
In all these scenarios, there is one interesting trend going through: number of lines of code does not necessarily match with the estimated (subjectively) business value that is generated by the project.
Generally, as it looks, number of lines of code is affected by a few other variables. Number of features implemented (delivered business value) is just one of these.
If we oversimplify the situation, the equation might look like this one:
So it looks that we (developers in general) tend to get more Lines of Code in our project as we increase:
- Features - amount of functionality delivered in order to generate business value.
- Revisions - number of minor rewrites and changes to the code along with the unit tests needed to prevent regressions.
- Complexity - number and depth of logical interactions that are needed to increase long-term stability and maintainability of a project.
We tend to deliver projects with less Lines of Code as we get:
- More Knowledge about the domain and technology, that allows us to achieve more with less.
- Higher Major Version which is the amount of practical knowledge, incorporated feedback and correct assumptions that were factored into the code.
Increased number of LOC usually results in even more of complexity and maintenance burden, resulting in codebases that are expensive to manage and evolve.
So the ideal project is short-lived tactical application that is delivered by somebody with the practical experience in the field, targets only a few highly specific tasks, is rapidly developed and delivered.
In a sense, a tactical application could be perceived as a small high-risk investment of development resources with potentially high Return On Investment.
More is less, yet it takes a bit of learning and experience to perform this transition. Probably the transition lasts the entire lifetime.
Share Article
Reader Comments (4)
I couldn't agree more with the concept of the "rapidly developed tactical application". Such (web) apps can bring a high added value for the business at a cost of 1-2 weeks of work.
But they're not necessarily short lived. In my experience, such apps are polished over the first few months of internal use, and then, they become part of the company's internal processes.
I'd say 80% of the features are done in the initial development, 20% during the next three months, and routine maintainance (e.g. stuff like security updates for the underlying framework) is negligible.
Aymeric,
I agree about the initial delivery of the 80% features in a tactical app (common 80/20 ratio) and that short life span is not necessarily that short.
However from my experience sometimes it is really hard to tell right from the start, whether a certain tactical application would live long enough or would simply be dispatched after a few weeks. This is common to young enterprises or established companies exploring their business problem domain in research-and-development style.
However, when the tactical works out, it feels so good.
I like this post very much. I will go to share this in my twitter page...
Email Database
iew Rinat Abdullin's professional profile on LinkedIn. LinkedIn is the world's largest business network, helping professionals like Rinat Abdullin discover ...
Small Corner Computer Desk
Cheap Life Assurance Quote
Dolce and Gabbana Sunglasses
Female Hair Transplant
Hair Loss Solutions
Disney Minnie Mouse