An Eventually Successful Attempt at Continuous Improvement

With the first door done (two shelves), it was time to work on the second one. I had a mini-retrospective at this point. I asked myself what I’d learned and what I wanted to do differently. A few things came to mind. First was: More Power

This is Part 4. Other parts are here: Introduction, Part 1, Part 2, Part 3, Part 4, Part 5, Conclusion, Epilogue

For the first set of shelves, the only thing I used a power tool for was to pre-drill holes for the lag bolts for the ceiling mounts. Everything else was done by hand. For the bolts attaching the angle iron to itself to make the shelves, this was just fine (though I do recommend a ½ inch wrench with a ratcheting end…that made it much easier to get the bolts tight in a confined space).

For the lag bolts into the ceiling, I used a socket set and ratcheting wrench. Doable, but I have arms built for typing, not for torque. This was the single slowest step of the process and the one that would benefit most from optimization.

So for round 2, I decided that having a faster way to screw the lag bolts to the ceiling would make the job faster and more enjoyable. I headed to the home improvement store. (side note, you can gauge how good you are at home projects based on the number of trips you take to the hardware store. I averaged 1.2 trips every day during this project. On my worst day, I made 3 trips.)

I was looking for a ½ inch hex driver bit like this. I couldn’t find it available as a standalone piece. I found it as part of a drill/driver kit, but didn’t want to spend $30 on a 120 piece set just to get this one piece.

I headed to another store. When I arrived, the salesperson asked me “What are you looking for?” I replied, “A ½ inch hex driver bit.” He helped me look around and eventually said the last thing you want to hear when you are at a brick-and-mortar store: “Looks like we don’t have it, but I could order it for you. It will be here in 3 days.”

Frustrated and despondent, I continued to wander the aisles. I ended up in the section with drill/driver kits, hoping to find a really cheap kit that had what I want. After a few minutes of looking around, I didn’t find what I was looking for, but I did find what I needed.

I had fallen victim to the thing I always ask my teams to be on the lookout for: customers assuming they have the solution to their problem.

In my experience, by the time a development team hears about a problem from a customer, the customer and likely several layers of support or implementation have tried to solve the problem on their own but were unsuccessful. In their work trying to solve the problem they eventually hit a roadblock. What I usually hear is, “If only I could do x, I could solve my problem.”

Often, what they’re asking for amounts to a better band-aid or a hacked up solution created with duct tape. Don’t get me wrong, there are times when that is all you need to do, but most of the time both the customer and the development team are better served when the development team digs in to find out the real root of the problem.

Sometimes it takes asking the question several times to get the customer un-stuck from re-explaining the need for their band-aid solution. But if you stick with it, the real problem will be uncovered and it usually plays out one of 3 ways:

• There is already a solution to the problem, the customer just needed some education (more often than anyone would like to admit)
• What the customer is asking for is the actual solution (rare)
• The application does need to be changed, but not in the way the customer asked (most of the time)

The key point is when a customer tells you the solution, be polite but don’t accept it. As software development professionals (and by that I mean Business Analysts, QA and Developers/Engineers), we are in the business of taking problems as inputs and creating solutions as outputs.

It is easy to fall into the trap of taking a solution and building a solution, but it is a disservice to the customer and to our own creative abilities.

Enough of the soapbox and back to the story. I found a socket adapter for my drill. This one little piece solved my true problem. With this piece I can attach any size socket and drive it with the drill. Turns out I was trying to solve a very specific problem and I really needed a general-purpose solution.

• Solution masquerading as a problem: “I need a ½ inch hex driver bit for my drill.”
• Real problem: “I need a powered way to drive a ½ hex bolt.”

Subtle but different. One is a binary. Either you have the ½ hex driver bit or you don’t. The other is a problem that could have many solutions.

I had forgotten one of the most important lessons I’ve learned about software: Never accept it when a customer tells you what the solution is. Keep talking to them until you find out the real problem.

Had I asked the right question, (or had the salesperson asked me the right questions) I would have saved a trip to another store, since the real solution to my problem was at the first place all along.

I’l call this my first mistake.

My next mistake was thinking that because I’d finished one set of shelves, I could assume that the second set would be identical and skip a few steps to speed things up.