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.

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…

When I first measured this it was 50%. In the meantime, we’ve added features, services and a new source data feed. Still 5% of our current codebase is localized terms of use and privacy policies that didn’t exist in our old website. So, growth of the codebase is something to watch but I’m not sweating it yet.