When I began in the computer business in 1990, I only wanted to design software. I had no interest in networking, troubleshooting or data recovery. If you had told me back then that one day I would be networking computer hardware and doing emergency data recovery, I would have thought you were honest-to-God nuts!
The realities of the marketplace had other plans for me. My programming customers began to ask me to deal with various troubleshooting issues even though I didn’t really know what I was doing most of the time. They didn’t care about my lack of experience, because I was the closet thing they saw as a solution to their problem. This is how I acquired most of my troubleshooting knowledge and experience.
Over the years, my small business evolved into two enterprises under one company roof: computer repair and application development services. To give you more of a perspective, the PC troubleshooting business is relatively easy to find and tends to be more safe and predictable. This is because the computer repair engagements are relatively brief in duration and they are more apt to be specific, well defined tasks. In other words, troubleshooting has relatively few variables and it isn’t very subjective in nature. This is not true of the programming side. Software development can be highly subjective, because people can add and change all sorts of programming functions within the project during the design process. In fact, the larger the project is, the more subjective and unpredictable it tends to become. If a software design project is not well managed with a good set of controls, it can be as treacherous as drag racing on a sheet of ice!
Because the troubleshooting side is far safer than the programming side of the business, I have created a sort of “operational doctrine” for the company as a whole. The programming business must compete against the troubleshooting business. However, the troubleshooting business does not compete against the programming business. To clarify this, a particular software development project has to be so attractive to me that I am willing to break away from the safer troubleshooting business to go ahead and bet my time and resources on it.
What I am really doing here is building up the software development side of the business with better quality projects and customers. This obviously makes it much less of a risk for me. If I can’t find the software design project that makes good sense, then I’ll just go right back to the safe, predictable troubleshooting work. Regardless of which division of the business I am working in, I always bet my time on good risks. The undesirable projects and customers will stay on the outside looking in – as it should be.