Continuous Process Improvement — Deliver Less Code at Better Quality to Achieve More

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)
Websites 39,981 Websites 27,071
Admin websites 15,011 Data ingest/processing app 6,176
Shared library 2,716
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

Spiral Staircase

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.

Continuous Process Improvement – Doing Less

burn-up2

I’m wary of the cliche’, “doing more with less.”

When I started in my current role, my team consisted a development manager, a product manager, a business analyst, three developers, an outsource/offshore arrangement of 6-18 developers with its own full-time relationship manager and me, a non-individual contributor tech executive. We worked with a product team of three. We built our main US and six other variations over the course of 12-16 months – which was a great success in the eyes of our sponsors.

Five years later, my team consists six developers and me. I have all the same responsibilities but get to code half-time. We still work with a product team of three. When we want to flex, we co-locate two or four contract developers onsite. These contractors rotate through pairing with staff and perform as part of our team.

Last year we rebuilt all those corporate websites while still delivering a backlog of other work including a direct to consumer website that generates millions in revenue. We did this with half to one third the development resource and with developers shouldering a broader set of product and operational responsibilities. We accomplished this without schedule pressure or extraordinary efforts. In fact, the effort appeared so routine, so non-heroic it’s hard to appreciate the accomplishment.

To characterize this as “doing more” is profoundly mistaken. If you dive into each effort, you’d see we built less and wasted less. Less production code to change and maintain, less beloved but little used features, less idiosyncratic and unnecessarily difficult implementations, less waste in the process of defining and delivering work. Our newer codebase consists of roughly half 65%* of the production code of our old site.

You accomplish more by doing less. I know this sounds very affirmational and non-specific. I’ll describe how we accomplished this in future posts…

ProgressVisualizer – visual reporting for your Trello boards

ProgressVisualizerI’m working on a pet project I’m calling, for now, ProgressVisualizer. It is intended to be a quick and easy way to create visual reporting for Trello boards.

Trello is the first tracking tool my team finds so easy to use that we’ve largely stopped using our physical cork board. It offers simplicity, openness and doesn’t impose unnecessary assumptions. It offers an API that lets you interact with your data and webhooks which allow you to do so in near real time.

I’ve tried to follow Trello’s lead and make ProgressVisualizer easy to use. It is a tool intended for leads and managers who want burn ups, reports and other charts, don’t want to spend alot of time crafting reports for themselves, and believe they should impose as little overhead on their teams as possible.

ProgressVisualizer sample charts and reports

ProgressVisualizer sample charts and reports

ProgressVisualizer is a nights and weekends project. I don’t know what it will become. That said, it’s more than a prototype. I respect your privacy, user profile information is encrypted, and I have provided the ability to export and destroy any data collected by the site.

Right now, I’m gathering feedback and suggestions, so if you use Trello, please try ProgressVisualizer and let me know what you think.

Ruby on Rails Reading List (kind of)

A student from RailsBridge NYC asked me for a reading list. Rather than focus on Ruby or Rails, I broadened the topic to software writing and writers I look to for inspiration. Here’s my reply:

The best book on Ruby language is the The Well-Grounded Rubyist by David Black. The Ruby documentation is pretty handy, especially the API pages http://ruby-doc.org/

For the Rails framework I dive into code and rely on google searches of Stack Overflow Q&A’s and the rails docs http://api.rubyonrails.org/ for answers to specific questions I run into.

For developer practice, I’ve been reading James Shore (The Art of Agile Development), Diana Larsen (Liftoff: Launching Agile Teams & Projects) and Jean Tabaka (Collaboration Explained: Facilitation Skills for Software Project Leaders)

For inspiration, I love The Existential Pleasures of Engineering by Samuel Florman and To Engineer Is Human: The Role of Failure in Successful Design by Henry Petroski.

Thought leaders who helped shape my values as a developer, product person and development manager are Jeff Sutherland, Ken Schwaber, Bob Martin, and Steve McConnell.

For online training resources, my team and I are using RailsCast, ThoughtBot, RubyTapas, Code School.

RailsBridge NYC

I am a coder and hiring manager for Rails developers. I am father of a daughter who aspires to a career in science and technology. For both reasons, I am grateful that there are programs like RailsBridge that introduce Ruby and Ruby on Rails to women interested in the technology and hopefully, a career in software development.

Bianca Rodrigues provides a nice, brief description of the RailsBridge NYC workshop June 6th.

It was great to meet other newbie Ruby developers who were going through some of the same beginner pains that I was. The workshop was a positive experience, and gave me the push I periodically need to keep myself immersed in technology. (read the entire post)

There is a large body of research and writing (including my own paper) on the fact that women are drastically under-represented in software development disproportionate to other careers in science and technology.

If you are an experienced developer, please consider volunteering. I participated as a TA and it really only took two evenings and one full day of my time to be of use to this great program. The experience of coaching is both a joy and a refreshing opportunity to see what you do through other people’s eyes.