Valued Lessons

I've learned. I'll share.

January 21, 2008

Garlic Programmers for Silver Code?

I just read Larry O'Brien's article about there being no silver programmers. He makes the case that although there may be great variance in programmer productivity, "the significant thing is not that some professional programmers are awesome, it's that some professional programmers suck". I admire Larry O'Brien greatly, and I think there is much wisdom in what he says here.

But I think he's missing something.

I have noticed a trend in my own productivity: my productivity varies greatly with the code base I'm working on. This variance may be greater than that between individual programmers. While many are rightly concerned with individual and team productivity, no ever talks about code base productivity. If we do, where does it lead us?

A few years ago, I was working for a small medical software company. One project was a new venture with a new code base. Though new, the code was already difficult to work with. Its design forced the developer to duplicate work. In my first meeting about the project, I was told we had to do lots of "fat fingering". I didn't even know what that meant. It turned out to mean typing almost the exact same thing over and over. I was horrified and ultimately wrote a code generation tool to automate the work. Though creating and maintaining it was extra work in itself, without it, doing many common tasks in this code easily took 3x longer than necessary.

After that project was "shelved", I was moved to the company's main product, which was older and had a much more "mature" code base. Actually, half was new-style (similar to what I had been working on) and half was old-style. The old-style code was even worse to work with. It was so bad that I was almost giddy whenever I could work on the new-style code. I'm sure you know what kind of code I'm talking about. Doing anything in this code easily took 3x even longer.

Combined, that's 9x slower. That seems too high. Is it even possible? How can a code base reduce productivity so much? Here are a few possibilities I thought of; I'm sure you can think of more:

  • Bad code leads to more code, and more code is slower to work with
  • Bad code is hard to understand
  • Bad code is dangerous to change
  • Bad code leads duplication of effort
  • Bad code leads to a slow change-compile-test cycle, leading to wasted time and loss of focus
  • Bad code from third party libraries can drive you crazy by crashing, malfunctioning randomly, or having little documentation
  • Bad code saps energy, interest, and morale

A bad code base makes any programmer less productive. Have you ever noticed that when you work from scratch with no code base to weigh you down, you can be much more productive? Imagine that as your baseline productivity. Now think of how long it takes you to accomplish something similar on a project that you're working on right now. How does it compare? I bet you're slower on the existing project.

But wait just a minute. Imagine if my list of the effects of bad code were reversed. What if, instead, it read:

  • Good code leads to less code, and less code is easier to work with
  • Good code is easy to understand
  • Good code is safe to change
  • Good code avoids duplication of effort
  • Good code leads to a quick change-compile-test cycle
  • Good code uses libraries which remove the need for "dirty work" and let you focus on the important problems
  • Good code is fun to work with!

A good code base makes any programmer more productive. Have you ever worked on a project that was so wonderful that you could crank out magnificent results almost effortlessly? Perhaps it has a great DSL embedded in it or has powerful infrastructure.

Even with conservative estimates, if bad code slows us down 5x and good code speeds us up just 2x faster, that's easily a 10x difference.

Maybe silver programmers don't exist. But is there "silver code"? What if there are programmers who are more adept at writing silver code? If they can make a code base that's just 2x easier to work with long-term, then that makes everyone that works on that code 2x more productive, possibly forever. If such programmers exist, then they must be extremely valuable, not so much because of their own productivity, but because of the effect they will have on the productivity of others in the future. Perhaps rather than "silver bullet" programmers that kill werewolves, these are just "garlic programmers" that ward of vampires.

Given that productivity can vary so much with quality of existing code, perhaps its worth looking for "garlic programmers" who will write code that will keep the rest us of productive long-term. I leave it as an exercise for the reader to figure out how to measure a programmer's garlic-ness :).

Labels: , ,

10 comments:

  2. " Good code leads to less code, and less code is slower to work with" ???
    ReplyDelete
  4. I can clearly recall the same situation occurring in my own professional career, within the past year sadly (i've since moved back into the world of my home office as an independent software engineer.)

    I was called in to work for a hosting provider to revamp many of their backend processes and interfaces, plus some automation and what not. The environment was in perl, so I know instantly that there would be some hellish times ahead. Anytime a code base exists in perl that isn't a series of small targeted scripts, there is generally spaghetti code and ugliness abound.

    I won't go into the specifics because I've already written that elsewhere on my own technical journal over a series of entries and months (http://www.codedevl.com) but a quick synopsis (and reason for leaving the job) was as such: I found my productivity reduced to a fraction of what it was prior to that position, and since leaving I have returned to my normal pace (a considerably high factor. What would take 5 days in that position takes about a day now, and I'm far more confident about the build quality of the current code.

    That situation partially revolved around the fact that the codebase was written by two people. One was a C code who got into perl but never stopped using C idioms, hence instead of using libraries and packages (.pm files), he named them with .h extensions and included them with the include directive. Global variables abound, no my, no use strict pragma (which is a must for well designed perl), and secondly the replacement programmer was the owner. He was not a coder by trade and it shows in his work. Yes, the system worked, but only with constant management and considerable human interactivity on a routine basis, including direct database manipulation of items which should have been controlled through coded mechanisms, especially the financial pieces.

    The level of depression I felt due to the disappointment by myself at the environment in which I was trying to operate made me realise that this problem was due to 10 years of a base codebase, and individuals that never took the necessary time to learn real best-practices, implement systems for peer review, setup versioning repositories (none had existed prior to me), and never learned that you shouldn't work on live systems as you're just asking for trouble.

    Either way, I do agree with what has been presented, I only wish I didn't have personal experience in that kind of environment, because it drained the life from me, and took away several months of productivity, which could have been spent engineering beautiful code and systems.

    eric
    ReplyDelete
  5. I couldn't agree more. It might take a bit more time initially to set yourself up, but you will definitely reap the rewards in spades later. Instead of fighting with your code base, you could be working with it.

    For my company LandlordMax, when I initially started it, I took more time initially to develop the underlying architecture, frameworks, etc. And what a difference it's made. If this hadn't been the case, there's no way we could have added so much new functionality in the amount of time we did!

    As well, there's a term called Developer Debt, or Technical Debt, which basically means that over time you will dramatically increase your cost to do anything if you don't do it right. It can quickly compound out of control.

    If you're interested you can read about it here.
    ReplyDelete
  6. one mans treasure is another mans trash.

    I'm sure the people who wrote your 'bad code' thought it was great and easy to work with at one time.
    ReplyDelete
  7. You may be missing (or misunderstanding) the cause/effect relationship between your "good code"/"bad code" examples and the "results side" (you may not be - it's always possible I'm just not paying enough attention to what you've written!)

    Basically, it's not a case (for example) that if you write "good code" it'll be easier to change: rather if you make your code easier to change, then it'll be good code.

    So:

    * If you write less code to achieve the same result, it'll be good code.

    * If you write code that's easy to understand, it'll be good code.

    * If you write code that's safe to change (I'm thinking unit tests, good naming conventions so the next guy knows EXACTLY what you're using that variable to store, etc.), then it'll be good code.

    * If you avoid duplicating your efforts (i.e. if you spot that you're doing it the first time you see it and change your code to avoid doing it in future), then you'll write good code.

    * If you write code with the change-compile-test cycle in mind (build scripts, continuous integration tools, automated unit tests), then you'll produce good code.

    * If you use tested reliable libraries for the common stuff and focus only on those factors unique to your problem, then you'll produce good code.

    The exception is that last one - the good code does cause the "fun" (and the bad code causes the stress).
    ReplyDelete
  8. The "permalink" to the silver programmers article is broken, but this link seems good: http://www.knowing.net/index.php/2008/01/14/no-silver-programmers/
    ReplyDelete
  9. Thanks, Dan. I updated the link.
    ReplyDelete
  10. Big Ball of Mud (1999):

    "It is interesting to ask whether some of the differences in productivity seen between hyper-productive organizations and typical shops are due not to differences in talent, but differences in terrain. Mud is hard to march through."
    ReplyDelete

Subscribe to: Post Comments (Atom)

Blog Archive

Labels

Google Analytics