Why it’s 90% not about ‘less code’

I hear a lot of talk about ‘less code’ being something we should favour.

[Edit - I should qualify that by 'favouring less code' I mean favouring a shorter class file or fewer classes in the code base, not splitting long methods into shorter methods or large classes into single responsibility classes, both of which I'm absolutely sold on.]

I disagree, and out of curiosity I just did a little experiment to see whether my feeling was well founded.

I wrote a ruby script which counts the words in source files. It’s not perfect but it’s good enough for this purpose because if it’s inaccurate it’ll err on the side of over-counting rather than under-counting. It counts = as a word if it’s surrounded by white space for example.

I can touch-type at 80 wpm. Here’s how that expands up if we imagine that I can type constantly, machine like, while I’m coding. (Of course I can’t, but bear with me).

  • 80 x 60 = 4800 words per hour
  • 60 x 8 =  38400 words per day

I just ran my script on the src and test folders of my main project. I’d estimate that this code base has taken me 200 (or more) working days to write. This 200 days excludes project management time, coaching other devs, client meetings etc. This is 200 days of quality time Stray spent with TextMate.*

The results from the script are kind of mind blowing:

src: .as – 921 files / 58933 lines of code / 129938 words of code
Typing this project should have taken 1624 minutes, which is 27 hours or 3 days.
test: .as – 718 files / 61457 lines of code / 143728 words of code
Typing this project should have taken 1796 minutes, which is 29 hours or 3 days.

Typing the code in my project should have taken 7 days (the 3 days is a round down on both figures). It’s interesting to note that I write more test code than production code – I find that reassuring, I’d actually like to see that proportion favour test code even further.

But here’s the takeaway: Of my 200 days spent writing this code, only 7 days were spent actually writing it.  What was I doing with the other 193 days of time?  Thinking about what code to write.

Even if we assumed that I threw-out a third of the code that I wrote, that would only take us to 10 days spent writing code.

95% of time spent writing code is spent

not writing code.

So – even if we doubled the importance of writing code, and called it 10% of our effort, 90% of our concern should be on making our code easy to understand and hard to break.

Sometimes a shorter implementation is less to read and less to think about. But frequently it isn’t.

You can find out how much time you don’t spend writing code with the ruby script here  https://gist.github.com/771048

(and thanks to Mr Hallman for the original countLines script I hacked to make it)

Give your code 5 minutes of love

The metrics show that my project consists of about 1650 files. I like a lot of small classes and it’s a big project. I’d estimate that half those classes are events, signals, bootstraps, interfaces and VOs that are so simple that there’s nothing to refactor within them.

So maybe 800 of those files are classes that have something really meaningful inside them – either source files or interesting test cases. The perfect time to refactor your code is when it’s passing unit tests.

I think my code base is healthy on the whole (robotlegs FTW in the war of attrition against code base hatred). But If I’d taken 5 extra minutes on each meaningful class and test, when the class first became ‘part’ of the app, before I closed the files, to do a little extra code craft and really polish the code, I would really *love* my code base. And it would love me back.

Based on this project’s metrics, it would have cost me 20 minutes each day. I’m pretty sure that those 20 minutes would have paid off in saved thinking time, and if not then I’d have made them up in less internet browsing / twittering / youTube watching yada yada.

So – my 2011 new year’s resolution is to give every meaningful class 5 minutes of love right when I would otherwise close it. Anyone care to join me? And remember – it’s 90% not about less code.

* A lot of this time is actually in short bursts which TDD makes much more productive.

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed
  • http://twitter.com/s9tpepper Omar Gonzalez

    I completely agree, I would think that 90% of your time coding is actually spent _reading_ code as opposed to writing it. The decisions that I personally make in regard to how I write something in code is driven by the ability to read it, hence, more concise, short, easier to read code is what I mean by less code is better.

    I would even go as far as to say that the amount of time actually typing is actually even less than what you have calculated because your word count does not take into account all of the auto-completion that coders use if they’re taking advantage of the IDEs that they’re using. Or the automatic class/method generation features of many IDEs.

    By shorter code, I mean making your code legible, short, and to the point. This doesn’t mean throwing convention out the window, it just means that it should be easy to read, as this is what you spend the most time doing. I like my lines of code to read almost like I’m speaking in plain english. So I guess what I’m trying to say is, its 90% about writing legible, clear, clean code. It’ll most likely be you that has to come back to this later, so I try to make it as easy for myself to read it when I need to come back to it and modify/expand it.

    • http://www.xxcoder.net Stray

      I concur – except that I think often ‘longer’ is easier to read than ‘shorter’.

      I’ve worked with devs who liked to abbreviate variable names to 3 letters. Argh! I do realise that’s the antithesis of what you mean.

      But often you can refactor a main method, even of a few lines, into 2 or 3 other methods that describe intent. That kind of refactor results in longer code, but if you ever come to read it your comprehension is aided by the descriptive function name that tells you *what* exactly this code is doing.

      For example – breaking out a lazy instantiation into a protected getter can really clean up a method that was otherwise starting out by checking for null in something that really it just wants to use.

      So – while concise is useful, it would be further down my list than readable and descriptive.

      And yes – I think I probably spend 98 – 99% of my time not writing code, but I figure even the most efficient coder can’t get to more than 10% of time actually typing.

      • http://twitter.com/s9tpepper Omar Gonzalez

        hah, I totally agree… except I see as refactoring long methods to 2 or 3 short methods less code… as in, “less code I have to read at one time”, which ultimately goes back to the main goal, more readable code. And yes… short variables are not what I meant either, variables should be descriptive and as long as needed to convey what they stand for or do.

        So I think we’re talking about the same concepts with different terminology, or terms used differently at least, but I think we’re on the same page.

        • http://www.xxcoder.net Stray

          Ah yes! Less code per method definitely = good :)

          Some people mistake less code for ‘less lines of code in the whole file / app’. Yuck!

      • http://twitter.com/80g Andrew D. Goodfellow

        Ah, the 3 letter method/properties are a pet peeve of mine.

        I always make my names very descriptive, even though they can become long. In 5 years when another developer has to maintain my work they will have a much easier time.

        At least, that’s my hope. :)

  • http://twitter.com/boobiestar boobiestar

    right on! what’s physically (or virtually) written down is the end result of all the processes, architecture, planning, variables, conditions, designs and layouts programmers have to take into account in the code they write.

    • http://www.xxcoder.net Stray

      We do a lot for our dollar, don’t we? Ta for stopping by.

  • Codexus

    Less code is almost always better, all other things being equal.

    This is because shorter code means more readable, easier to maintain code. Not because it’s faster to write. It isn’t.

    If for the same task, you write more code of the same quality it means that there is redundancy or unnecessary complexity which are going to be a source of problems once you start making changes.

    Writing readable and maintainable code is still the priority. Clear and concise code is the natural result of doing so.

    Things like nondescriptive short variables name or tricks to keep things on one line are obviously bad and not even considered shorter code at all.

    • http://www.xxcoder.net Stray

      “… all other things being equal” – that’s a seriously loaded throwaway clause!

      If you’ve reached a point where you’ve found an optimum, or just really good, solution, then implementing the same interface and structure with fewer variables might be advantageous, but I’d argue that people less frequently reach those optimums because along the way you pass through stages where there is more code.

      I also think that ‘more code’ solutions – more, better separated, classes – can often be simpler.

      I’ve never met a ‘less code’ focussed coder who wrote code that I coveted. In fact, in the latest round of ASSignals edits, I notice that Joa – a coder who is, like the library’s originator Robert Penner, on another level – just as often advocates a ‘more code’ solution.

      So – I think what you’re saying makes sense in the abstract, but I don’t think I’ve ever seen “more code of the same quality” in the wild. Generally “less code of lower quality” vs “more code of much higher quality” is what I come across.

      Do you have any examples?

  • http://twitter.com/nordhagen Øyvind Nordhagen

    That 9/1 ratio of thinking vs coding is mentioned in several books, most notably in “Clean Code” and “Refactoring”. When I read it the first time I immediately knew that I had always known it in the back of my head, but it really got me thinking and subsequently changing the way I write code. It is one of the reasons I cannot live without the refactoring tools provided in FDT.

    But on the topic of this post I would say that the only right amount of code would be “adequate” is better than too little or too much; verbose enough to be read with minimal mental overhead, but concise enough to keep you from loosing your train of thought. Reading and thinking about code being 90% of the work, it should be given an equal amount of importance. We tend to write the code we need to pass the tests and make the client and designers happy, but facilitating effective code comprehension for ourselves and others should be an ongoing task of at least equal importance. We will after all thank ourselves 90% of our work hours.

    • http://www.xxcoder.net Stray

      “facilitating effective code comprehension for ourselves and others should be an ongoing task of at least equal importance. We will after all thank ourselves 90% of our work hours.”

      I love that – it’s so concise. We will, indeed, thank ourselves 90% of our work hours!

      How odd – I’ve got and read most of both Clean Code and Refactoring, and I missed the 90% ratio in both of them. Thanks for pointing it out – I shall now arm myself with page reference numbers and next time I make this argument I’ll have their back up!

  • http://opinionated-programmer.com/ Jo Liss

    Don’t you edit and refactor though? The actual amount of code you have written should be at least twice the amount of code in your project right now, I think. (It’s not completely trivial to get word counts from your version control system, though it might be interesting to try some time.)

    And if your code gets longer, the time you spend on editing and refactoring blows up too, plus your thought process gets disrupted.

    I honestly don’t have much of an opinion on the less-code thing, but I’m not sure if I find the argument you give completely convincing. Certainly, when I go from Ruby to Java, my productivity drops substantially, and it has a lot to do with Java’s verbose and unexpressive code style.

    • http://www.xxcoder.net Stray

      I’m a huge fan of refactoring – which is why I already doubled the time involved to get to the 10% figure to allow for that – as you thought, I went for twice the amount.

      I think you’re right that editing and refactoring is more important than writing, but I don’t think “as your code gets longer the time you spend on editing and refactoring blows up too” is accurate. I think it’s (potentially) the opposite.

      For example – I could have a single class “LoginController” that has less code than a large number of individual commands that implement the individual pieces of action.

      But if I realise (this is a real case from my workload today) that we’d like to strip whitespace from around username / password field entries, it’s a lot faster to implement that if I open the login.controller package and see SubmitLoginValuesToServiceCommand, which only has one simple function of a few lines.

      So – rather than being disrupted, my process is optimised by having taken the more code approach – provided the code is well named to reflect its single-responsibility.

      Ruby vs Java – I can’t claim to be an expert because I only dabble in Ruby – but I some of that difference in speed down to the everything-is-an-object features and “The Ruby Way” mindset rather than verbosity. For example – being able to do numPages.downTo… instead of making a loop.

      Plus Ruby is dynamic… which also has tradeoffs in terms of coding time vs bug-hunting time.

      But I also only hack together relatively minor things in Ruby rather than building large apps as I do in AS3, so I couldn’t really compare the two as I can hack pretty fast in AS as well if I don’t need to care where the bodies are buried!

  • http://opinionated-programmer.com/ Jo Liss

    (I definitely agree with “90% of our concern should be on making our code easy to understand and hard to break”, by the way.)