Continuous Process Improvement — Deliver Less Code at Better Quality to Achieve More
April 14th, 2014
In my last post I claimed we rebuilt our website properties with with half to one third the developers and with “about
half 65%” the resulting code. All to justify my claim that “You accomplish more by doing less.”
Now, I’ll back that claim with some metrics.
Lines of code
There are a number of tools for measuring ruby code size and complexity. The metric_fu gem does a good job a aggregating them.
But because our retired rails application is six years old, I resorted to the perl based cloc to count lines of code. I excluded standard libraries and counted code in the app and lib directories supporting websites common to both codebases.
|Old Application||Lines of code (LOC)||New Application||Lines of code (LOC)|
|Admin websites||15,011||Data ingest/processing app||6,176|
|Total Old||54,992||Total New||35,963|
Our current codebase is 65% the size of our original*.
Code size is a predictor of defect count and ongoing maintenance. That our current codebase is 35% more efficient at delivering roughly the same perceived value implies it is materially less expensive to maintain.
Take from this that lines of code is a terrible measure of productivity.
Less code is not our only indicator of the health
As measured by rake stat, we now have 3.6 lines of test code for every line of production code. Our old codebase measures 0.4. Our new applications have 9 lines of test for every one in our old.
Test lines of code is not a measure of test coverage or quality but remember I also work in this code. I know from direct experience that the new tests are more thoughtful — less fragile and opaque — better at testing real business logic with real data. We have invested in improving our test practice.
Better tests and better test coverage allows developers to take more initiative in changing and optimizing code. We can turn around features faster and we can improve our code with less fear of breakage. It’s a virtuous circle.
Again, we rebuilt our corporate websites with half to one third the development resource, 35% less code and better test coverage. We did this over a similar time frame in one week increments without schedule pressure or extraordinary efforts.
For the product and executive managers out there
Managers want predictable delivery in short cycles. But that is an outcome. You achieve that outcome by reducing waste and building with quality.
If you don’t make quality your priority, your developers — out of loyalty and best intentions — will not build with quality. And that leads to larger, less maintainable code, longer and less predictable delivery cycles. The opposite of what you want.
Allow developers their due as craftspeople and professionals. Instead of banging the drum on delivery and delegating responsibility for quality, commit time and attention to building with quality and your team will deliver.
Next time, I’ll dive into how and why our practices have changed over time…