Dunny diver: colloquial and humorous name for a plumber in Australia. (In Australian English the word dunny is used informally for toilet.)
I’m sorry that last week’s post wasn’t about anything IT. Most weeks some random event starts a chain of thought about software that becomes my topic. This might be because the world runs on code. Or maybe because programming is about solving problems. Life is full of problems, and we need problem-solving skills.
The plumbing problem
Because I am an organised (aka OCD) kind of person, I photograph our municipal meter readings every month. I track these in a spreadsheet to calculate and compare daily and monthly usage. (I already admitted the OCD part.)
So I noticed when our water consumption increased a few months ago. It worried me, but there were a few possible explanations. When last week’s reading showed a big jump, I knew something was wrong. But this is a big property, with lots of buildings, including the training centre. How can I find the problem?
Lewis and I started debugging:
- I phoned my favourite (but expensive) plumber for advice.
- I phoned a leak detection service for information and a quote.
- We walked around the property to look for unusually green areas or wet spots.
- We checked for leaking outside taps.
- We closed different sections of the water pipes to narrow down the options.
Step 5 produced some strange results. We spent a long time trying to make sense of these. Then we realised the results were only strange because of the current layout of the property. Many years ago, the buildings and layout had been very different.
Finally we narrowed down the options to two likely sources. Time to dig deeper (and I mean that in the literal sense of the word).
This is just like software
Either you’re saying “Yeah, I get that”. Or you’re saying “Huh?”
There is no perfect system. At some stage code will cause problems. But sometimes, you need to be monitoring your system to pick it up. Eventually the problem will become too big to be missed (like a massive water bill). But monitoring is a way to find the problems before they really hurt.
Then you have to investigate. And that requires a logical, step-by-step approach. You eliminate options. You form a hypothesis. And when you think that the next tests will prove your theory, something weird happens. And you have to re-evaluate your theory. And sometimes the weirdness may be due to the long-forgotten history of legacy code.
Eventually you narrow down the options. Then it’s down to the nitty gritty to check, find, repair and test. All seems well, but you won’t know for sure until the next time your account comes due.
There might be a stupid question
Ever had a manager or client ask “How long will it take to fix the problem?” That’s guaranteed to annoy any programmer. You can’t know how to fix the problem until you know what the problem is.
And do not ask “How long will it take to find the problem? I tell delegates on a course that there are no stupid questions. But that last one might be a stupid question.
In the words of Steven Levy:
“There has never been an unexpectedly short debugging period in the history of computers.”
Expertise is expensive
After digging up to check the two possible culprits, we’re back to square one. Neither one is the problem. So it’s time to call in the big guns – the expensive leak detection service. And then the even more expensive plumber. We amateurs don’t have what it takes.
And there’s a lesson there for managers. You actually need the expensive, experienced developers. A plumber is not a plumber is not a plumber.
I’m always hopeful that you’ll share your thoughts on the topic.