Serviceability

Recently, Ken Boucher brought up a term on the Maverick Software newsgroup: Serviceability. He defined it as such:

What’s serviceable?
Serviceable is the Holy Grail as found in Indiana Jones and the
Last Crusade. It’s meatball surgery from M*A*S*H 4077. It’s
a picnic table. It’s breakfast at 8pm in the kind of diner that
you just can’t find anymore because they don’t make diners
that like anymore.

Serviceable isn’t sloppy any more than it’s precise. It may not
be fancy but it delivers every time. You probably can’t but it
anymore but your grandparents still have one in the tool box or
in the kitchen. (My parent’s stove is in it’s 30’s and still works
perfectly).

It’s a Louisville Slugger. The kind of unspoken solidness that
reputations are built off of.

Serviceable doesn’t come from TDD or refactoring or NLP.
They’re just tools. And when the tools become more important
than the product it shows. It’s what happens when the customer
comes first. Not XP. Not UML. Not racking your mind trying to
find the phrase that will let you enter the zen state of no-mind.
It’s just rolling up your sleeves and delivering to the customer.

Serviceable. Maybe it’s not the best word, but it’s the kind
of word a craftsman would use.

Indeed. But what really is serviceable, and can it fit in with software development? From the dictionary:

1. Ready for service; usable: serviceable equipment.
2. Able to give long service; durable: a heavy, serviceable fabric.

So, code would be serviceable when it was “done”, meaning it was ready to be used by the customer. Also when it was able to give long service. So what does it mean to give long service? If you had to repair the VW bug engine every week, is it still serviceable? Let’s see what else is out there…

From a Thesaurus:

1. In a condition to be used: employable, usable, utilizable. See used/unused.
2. Serving or capable of serving a useful purpose: functional, handy, practicable, practical, useful, utilitarian. See used/unused.

I like the second one. “Capable of serving a useful purpose.” As J.B. Rainsberger once put it (and I believe he got it from Mary Poppendieck), code that doesn’t deliver value to our customers is just inventory. Inventory isn’t serviceable. Interesting. What else?

From WordNet:

Meaning #1: ready for service or able to give long service
Antonym: unserviceable (meaning #1)

Meaning #2: having a beneficial use

Meaning #3: intended or able to serve a purpose without elaboration

2 and 3 are both interesting. Again the beneficial use definition. Something is serviceable when it is useful. 3 is especially interesting, “without elaboration”. Elaboration? “The process of working out in detail by labor and study.” Ah. So, maybe not just useful code, but code that doesn’t require labor and study to understand how to use. Sounds like we’re getting somewhere. Clear, useful code.

From Wikipedia:

In civil engineering, serviceability refers to the conditions under which a building is still considered useful. Should these limit states be exceeded, a structure that is still structurally sound would be considered unfit. For example, a highrise building could sway severely and cause the occupants to be sick (much like sea sickness), yet be perfectly sound structurally and in no danger of collapsing. This building is obviously no longer fit for human occupation, yet since it is in no danger of collapse, the structure would be considered as having exceeded serviceability limit states.

Which I think fits in with the other defintions. Something that may meet all the requirements, but doesn’t give value isn’t serviceable. The building in the example, though it met all of the specs laid out by the customer, and people could indeed live there, didn’t ultimately give value to the customer because they wouldn’t be able to make any money off the building.

A very interesting thought indeed.