Mar 10 2009

Defect leakage: a metric for quality code

It’s all very well to have a feel for how good your code is, but knowing and proving that you’re producing quality code is another matter. Catherine Powell tracks code quality, we don’t but should, and probably will be soon.

On the Abakas blog (a good read if you’re concerned about or responsible for software quality) she writes about what is perhaps the most useful metric that software developers can track: defect leakage. It’s the measure of the number of bugs found first in the field by the client (or users). There are a number of ways of reporting defect leakage: raw numbers is one, but one that is probably more useful is the ratio of bugs found by the client to bugs found by us. That gives an indication of how thorough our testing processes are.

A side effect is that to report this metric we need to track bugs in some detail, and this gives us the ability to break the metric down and pull more information out of the reports. Which areas have good coverage (as shown by a low leakage ratio)? Which areas have a high defect leakage ratio and need more attention before release?

Catherine Powell writes:

… measuring defect leakage requires you to really consider every customer incident, and that kind of introspection helps me see patterns in problems. It really points out where our coverage is lacking and, conversely, where our product is pretty good.

I like that!


Mar 9 2009

Siftables: toy blocks that think

MIT geeks have all the fun. Here’s a talk from this year’s TED where grad student David Merrill demos the coolest toy blocks ever.


Mar 9 2009

Does HTML validation matter?

Jeff Atwood of Coding Horror has posted a very well thought out piece on the perils of taking web site validation too seriously. Concerning XHTML validation he quotes James Bennett:

The short and sweet reason is simply this: XHTML offers no compelling advantage — to me — over HTML, but even if it did it would also offer increased complexity and uncertainty that make it unappealing to me.

and goes on to voice his own opinion:

The whole HTML validation exercise is questionable, but validating as XHTML is flat-out masochism. Only recommended for those that enjoy pain. Or programmers. I can’t always tell the difference.

He knows us too well.

His advice at the end is:

  1. Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
  2. Nobody cares if your HTML is valid. Except you. If you want to. Don’t think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.

Ah, perspective, that rare and valuable thing.

Read the whole article yourself; if you create web pages it might give you a new perspective and is certainly worth 5 minutes of your time.


Feb 26 2009

KISS DRY YAGNI

Three concepts that I’ve come across in the software development world that apply quite nicely to the real world also are KISS (which of course originated in the real world), DRY and YAGNI.

KISS

Keep It Simple, Stupid! We’ve heard it often enough, and it’s still good advice. When faced with a problem, especially one that promises to be dull to complete, it can be much more fun to come up with something elegant and/or hugely complicated just because we can. This happens surprisingly often in the corporate software development world, where the boredom of mindlessly dull tasks can be relieved by stretching one’s intellect with a bizarre solution.

Sometimes this is a good thing. But if someone is ever going to have to maintain, fix, or modify what we’ve done, they’re in for a rough time. And it can be quite an “ah” moment when we go back to our own code and can’t make sense of it. There’s a time and a place for ridiculously written code, but often KISS is still the best approach.

DRY

Don’t Repeat Yourself came out of the Agile (capital “A”) software development movement. If you’re writing the same code twice, you’re better off refactoring down to one use (perhaps referred to from multiple places). At one end of the scale this is the concept behind using maths libraries instead of writing your own. At the other end, some rather religious XP types won’t let any block of code appear anywhere twice no matter what.

My take is that this is an excellent guide that should be followed most of the time. However, if I’m writing a script to parse a couple of files that I know I’ll only ever use once, I’ll probably cut-and-paste the solution for two files rather than write a slightly more elegant DRY solution. It’s faster, easier, just as easy to read, and gets the job done.

YAGNI

You Ain’t Gonna Need It. Another spin-off from the Agile movement, this principle says that you shouldn’t build something just because you might need it some time later. Carried to the extreme it means that you wouldn’t put subtraction in your maths library if you only need to perform addition today. In practice, it means that we shouldn’t second-guess what’s required next month when writing our code this month. It’s (usually) not too hard to refactor for extension to the code. The time may well come when new functionality just doesn’t fit the current code and a major overhaul will be needed, but it would probably be a good idea by then anyway. Of course, if you know that you’ll have to persist data next month there’s no harm in making sure that this month’s code can talk to a database, but be reasonable.

(Side note: this principle seems to be violated by every J2EE project I’ve ever had the misfortune to come across.)

Example

Recently I was comparing Content Management Systems; let’s apply these three principles to a comparison of Joomla and Silverstripe.

KISS: Joomla has been around a while, and has a plethora of plugins and extensions. It changed the internal naming structure a few versions ago, so the online documentation (such as it is) is not as clear as one might wish. Silverstripe is a younger player with a smaller market share. It does the basics very well, and has a few plugins free available. Joomla is hugely configurable and has a variety of WYSIWYG editors available, while Silverstipe is simpler (and in my mind, cleaner and sleeker). Silverstripe wins on KISS.

DRY: As far as could tell from the quick assessment I had the time to do, both allow configuration to be done once to set the site up. Equal.

YAGNI: Clear disparities here. Silverstripe has either inbuilt functionality or plugins for basic requirements. It allows for reasonably straightforward development of additional plugins for other tasks. Joomla has a large amount of inbuilt functionality and about a zillion plugins (written by people of varying talent) available. There are dozens of ways of doing everything. It’s unclear what the “best” (or even “good enough”) approach is, and new users are either overwhelmed by the choice or try to install every plugin under the sun, with predictably poor results. Silverstripe the winner by a country mile.


Feb 23 2009

Wordpress themes

Bah! Changed from the “blackout” theme to a nice bright one, and it doesn’t handle images in posts well at all. Will fix tonight…


Feb 21 2009

Attractive and ugly web sites

Just for fun I took a quick straw poll around the office — what are the most attractive and ugliest web sites you know of in New Zealand? From this totally unscientific survey, I can report that http://www.specialsurprise.co.nz/ is the most beautiful, and http://www.cal-wilson.co.nz/ is the ugliest web site in New Zealand.

I’ll post all the entries Real Soon Now™