It’s a good thing we don’t charge by the lines of code we write in an application.
On a recent project, we’ve been keeping track of the lines of code, and it’s continually going down. You may be thinking — how is the project progressing? With less code, is the application doing less or providing less functionality?
Quite the opposite, actually.
Take for example, a simple story added by a user during a story-carding session:
“The Admin should be able to paginate through the lists of recent users who signed up.”
A developer might choose to write all this code themselves. He or she might think to themslves: “surely the community hasn’t solved this before, I’ll reinvent the wheel.” However, a good developer would choose to re-use a plugin, or library, or follow the best practices laid out by others. There’s a perfectly good plugin for paginating lists of results (one that we’ve contributed to) called will_paginate and it takes all of 30 seconds to install. By adding this plugin, one “line of code” now adds a standard form of pagination, versus 50 or 100 of reinvented lines of brand new code that may have bugs or defects. The will_paginate code actually provides more functionality, is more robust, has new features/bug fixes (as recent as a few days ago of posting), and is under active development. It’s a win-win for everyone.
Tests, plugins, and lots of simplification through refactoring. We use code-coverage tools to show us how much of the code is tested. We’re not just adding tests because we know it’s right — it helps us move faster and faster. It also helps us prove that what we built is what was asked for.
By “not adding more code,” we’re adding simplicity, not complexity.
The most important rule of software engineering is also the least known: Complexity does not scale linearly with size… A 2000 line program requires more than twice as much development time as one half the size. – The Ganssle Group (from Keep It Small – also mentioned in 37 Signal’s Getting Real)