Craftsmanship, Practice or Procreation?

Iwein Fuld

In the past years there has been much ado about the quality of software. Programmers have emancipated and evolved into software craftsmen. Metrics have been defined and honed to measure the quality of code and deliverable artifacts. More and more of our clients are asking for guidance in achieving higher and higher quality goals.

The discussion about software craftsmanship hasn't been all positive. Many developers that I've worked with express the feeling that certain levels of quality are only driven by the personal gratification of craftsmen and not in line with the economic realities of our trade. In this article I strive to establish guidelines in the compromise between quality and speed. I feel it is warranted to be more nuanced than the simplistic statement: "Going fast by going well". This is because "going well" can mean different things in different contexts.

I look for a line in the sand between improving quality to improve procreation and improving quality for mere self indulgent practice.

The importance of quality

Any developer with some experience intuitively knows the importance of quality. Reading and changing code is harder than writing it. If you've ever had to change code of suboptimal quality you've known that feeling: if only this code had gotten a little bit more thought when it was originally developed it could have saved so much headache. The quality of code is principally defined by three attributes:

  • Is it simple
  • Is it easy to change
  • Is it easy to test

I've asked many different developers to list the attributes of high quality code, and this top three was the result. When you think about it, it is kind of obvious. Whenever you look at the code, you're either there to fix a problem, or to implement a change. The time you need to spend on that is highly dependent on these three factors.

When is quality high enough?

So far we've seen only qualitative attributes. This is unsatisfactory for two reasons. First there is the lack of scientific value; we have nothing measurable, so any statements about quality have to be subjective. Second there is no way to predict qualitative results like cost of ownership in relation to quality. There have been many attempts to resolve this. There are intricate metrics like cyclomatic complexity, test coverage, entanglement and what not. All of these metrics have been gamed and abused. There is at this time no way to relate these metrics to the cost of changing the software. Sorry.

The only thing we have is estimations by human developers. How unscientific!

Estimations work adequately for cost predictions in agile processes, so maybe we can use them anyway. Even if we have no useful quantitative measures for quality it doesn't mean we're completely in the dark. We do have qualitative relationships that we can use to guide us in deciding what level of quality is required. We can use estimates to quantify them.

There are three variables that control the optimum quality:
- the proportion of time spent reading the software vs. writing it.
- the average cost of a defect
- the amount of changes expected

In a standard (agile) process we usually only estimate the cost of implementing a change. We often don't estimate the risk of the change. Also we don't estimate the change and its risk after a theoretical refactoring we might do. If we would do this we would have much more insight into the cost of not doing quality improvements.

Only invest if you expect a return

With the industry turning Agile slowly, it is becoming common practice to only implement those features that, after estimating them, seem to add more value than their cost. This can also be applied to quality improvements.

First you estimate the effort of a certain quality improvement. Then you estimate the reduction in effort for the remaining features if the improvement would be done and the reduction in risk of defects. This would give you a result for a break even point in the future. This yields a concrete argument to either do or not do the improvement. You can then discuss this with the guy paying the bills in a vocabulary that he understands very well.

Is polishing code just for practice a bad thing?

There is a time and a place for practice. If you don't practice you'll never get good. Nothing wrong with polishing some code, removing some dodgy lines here and there. Just because you can.

It is however not our god given right to polish the code until we rise to crescendo. Many times I hear complaints from developers like: "We never get time for refactoring, so that's why our code looks like this." And I often hear these countered with: "You should just take that time, because it is your job as a craftsman to create high quality code." The time spent polishing isn't for free. We should look for a smart compromise, that is our job.

Is there room for real Craftsmanship or should we all just hack

At Facebook developers are urged to HACK. They are very successful. So in certain context I believe that spending hours on polishing existing code has no place. Make it work and damn the source is a great strategy in many more places than you might think. But Facebook is not making airplane guidance systems. Or trading systems. Or route planners. If you make something that people depend on for their shopping, travel, income or even their lives, you have more responsibility to make sure it doesn't break.

But there is a big grey area between hacking and craftsmanship zealotry.

Figure out the forces that drive the costs of ownership in your context and use them to prioritize quality improvements when they actually make sense. And practice if you find the time of course. Only practice makes perfect!

I'm really interested in experiments you have done in making the cost and benefit of quality improvement visible. Drop me a link or a comment if you have something to share.

Comments (8)

  1. [...] Craftsmanship, Practice or Procreation? [...]

  2. Viktor Grgic - Reply

    November 3, 2011 at 12:00 am

    Hey Iwein,

    Great article!
    It's a very rational way of measuring the quality. There are still two problems:

    1. Estimation tips that you give are still very difficult to use. Remaining features is complete backlog, very uncertain and practically impossible to know if any features are going to benefit from improvement. Even if you know complete backlog in details, nobody knows which solutions are going to be chosen and therefore what the impact is on the existing code.

    2. I think that problem with "how much quality do we need?" is the lack of knowledge and lack of answers on other questions like "what is the impact of having bugs?" and "how big will our system become?" The more we answer these questions, the easier it gets to translate to required improvements. But, it is still not something we should measure, but simply talk about it all the time and let the feeling of experienced developers decide. "A smart compromise" is still important, but developers should be trusted and helped in making those decisions, not the guys that pay the bills.

    I agree with you completely on last two paragraphs. They seem to contradict with statement about how to measure.

  3. Albert Sikkema - Reply

    November 3, 2011 at 1:16 pm

    Hi Iwein,

    Great stuff.
    I always find that people don't take into account how long something will most likely run in production. For example: websites/front-end stuff usually gets dropped every 2-5 years. It's ok to have less quality there then in backend systems which tend to be maintained in production much longer.

  4. Iwein Fuld - Reply

    November 3, 2011 at 2:24 pm

    @Viktor
    Thanks for the comments. I agree that estimation is very difficult, even in general. The devil is in the details. To be more precise it is in the level of detail you use to estimate. Dan North mentioned that in his the more higher the level of detail, the higher the total estimate was. The tricky thing is to find the right level of detail, so that estimating doesn't take a prohibitive amount of effort in itself. This deserves an article in itself.

    On the second point you make also estimation at the right level of detail is essential. I don't agree with you that developers should be trusted in making the decision on what the best compromise is. In fact that is exactly what I am challenging. If something has impact in the long term on the productivity or stability of the system, only a business decision is appropriate.

  5. Jan Plas - Reply

    November 3, 2011 at 3:49 pm

    At the GOTO conference in Amsterdam I saw a presentation by Fred George of Forward (http://gotocon.com/amsterdam-2011/speaker/Fred+George , slides here: http://gotocon.com/dl/goto-amsterdam-2011/slides/FredGeorge_ProgrammerAnarchy.pdf).

    He describes their interpretation of "Agile working" as "Programmer Anarchy". Basically the programmers are much more in control of what they do and how they do it because of a much higher level of (needed) trust between business and development without some kind of manager trying to "manage" the process. Even to a point where he boldly states they do NOT use continuous integration, unit testing etc.

    In stead they do continuous deployment (to production) of (really) small building blocks. They rewrite those small modules without much ado whenever they get too messy or incomprehensible when a bug fix is needed.

    He gave one example where they re implemented an entire system from .NET to various other languages where they first wrote some central algorithm in Ruby, then again in Clojure, then another time in Clojure. Ultimately this piece of code was a nice little piece of code which (BTW) solved some bugs prior unsolved in the .NET system. Solely because the developers at their own discretion decided a complete rewrite was the best thing to do.

    I found it really interesting to see how people can work successfully using totally different practices than thought "correct" these days. I myself get a lot of itchy feelings all over when hearing about something like this... No tests at all, rewrites just because... because...? He also stated this, of course, does not work with just anybody. It's a cultural thing and a matter of experience as well.

    His case to state that they're not totally crazy, and this does work in their setting, was that Forward had a reported revenue of GBP 55 million last year, basically a million per developer (they actually employ more people of course). "Raise your hand if you can top that"....

    • Iwein Fuld - Reply

      November 3, 2011 at 11:26 pm

      @Jan I think you're referring to a very exceptional situation. Cool example!

  6. [...] Craftsmanship, Practice or Procreation? – размышления о балансе качества кода и потраченного на него времени [...]

  7. Rahul Agrawal - Reply

    November 15, 2011 at 11:15 am

    There are three variables that control the optimum quality:
    - the proportion of time spent reading the software vs. writing it.
    - the average cost of a defect
    - the amount of changes expected

    Iwein, once again a very nice topic picked by you. Thanks.
    If I keep in mind that the code that I write should be easy to test and debug, then I feel that my mind automatically forces me to prevent doing a lot of mistakes.
    And this does help me to improve the above 3 variables.

Add a Comment