Tool Choice as a Quality Issue

[article]

25 years ago, I thought it would be cool to have a mailbox that looked like my house. How hard could it be? It’s just a box that has the appropriate shape with windows and a door painted on the front. So, I designed my house-mailbox. It was going to be great:  how unusual and unique!

When I started building it, though, I discovered that it was easier to visualize than it was to build. I had to cut a roof with the appropriate pitch, which called for some odd angles. After setting the stops on my circular saw and measuring not twice, but four or five times, I managed to get the roof cut. I figured I would be able to make it work without using too much wood filler. Cutting the walls and bottom was a bit easier, since they were rectangular with no weird angles.

Then I had to assemble it. The pieces didn’t fit too badly, but the nails were difficult to drive straight and keeping everything square was a challenge. The roof didn’t fit quite right, but it was close enough. The bottom made everything hold together pretty well.

After filling the gaps with wood filler and a generous helping of caulk, it was ready for the paint. My wife did the detailed work (windows and door) and it was finally ready for its debut! I was proud of my work of art and was only mildly disappointed that our mail got wet when it rained.

Why had it been so difficult to produce a reasonable-quality mailbox? I had done significant remodeling in our first house and finished the basement in this one. This new project presented challenges I hadn’t faced before, though. It wasn’t until many years later that I began to understand the reason for my difficulty on this project. It was the tools I was using! A circular saw and a hammer were fine for home remodeling, but for the finer work required to build a mailbox, I needed tools that were suited to that job. The problem was not that I was unable to do the work, it was that I lacked the tools I needed to do that job well.

Many years later, when my young son showed an interest in the guitar, we picked one up for him at a garage sale. I played guitar on a semi-regular basis and thought it would be great for him to have the chance to try his hand as well. The first time I tried to tune it up for him, I realized there was a problem. I struggled to get all six strings in tune at the same time. It seemed that tightening one would change the others.  It took a lot of patience before I finally had them tuned correctly, but then I tried to actually play it. The strings cut into my fingers as I tried to push them down onto the frets. It required so much force that I was unable to play simple chords that were easy with my guitar.

I finally made the right decision; I would not subject my young son to the horror of trying to play that guitar! Why? Because it was the wrong tool for the job. It was a cheap and could not be made to sound good, regardless of the player’s skill. It was a sure road to disillusionment for an aspiring guitarist!

That incident (along with my seemingly increased skill as I added tools to my woodshop) made it clear to me that tools are a key factor in producing high-quality work. Years later, I was able to do a passable job of building decorative items out of wood. Yes, my skills had improved with the years and experience. But the biggest part of the improvement could be attributed to a workshop full of tools. Now, when I needed to do a specific job, I could reach for the right tool, and it would enable me to do high-quality work. Of course, the best tools in the hands of an amateur will not turn him into a genius, but a virtuoso with a bad violin will be at a severe disadvantage. It is very difficult to do great work when the tools are ill suited for the job.

As we contemplate a new SCM tool, we must consider not just the list of features and the tool’s cost. We must first look at the jobs that our people must do. How will the programmers use the tool? What will they need to be able to do with it, and what skills do they bring to the job? We must choose the right tool for whatever the job is that our programmers will be doing--one that will support not only them, but also all of the other people who will use it.

How could the wrong SCM tool affect the quality of our people’s work? Let’s look at a few examples:

·       A tool that does not support the way the programmers work will frustrate them, making them more likely to subvert its controls. When they do, their code is likely to be lost or over-written resulting in a mad scramble to rebuild what was lost. Code written in a hurry is ripe for quality problems.

·       If your environment requires branching code into multiple concurrent versions, then ultimately merging them back together again, a tool that does not support these things cleanly will result in errors as the programmers struggle to bring the divergent versions back together again.

·       A tool that does not provide the reporting or status information that your people need will leave managers and technical people alike vulnerable to making wrong judgments as they estimate (or guess at) the information that they cannot see.

In order to produce high-quality software, we must start with personnel who have the requisite skills and knowledge. We must then support them with tools that are appropriate to the jobs they must do and that are designed to meet their needs. A good guitar can make even a semi-skilled player (like me) sound good. Give your virtuoso programmers the tools they need to build true masterpieces. 

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.