June 22, 2018
Hot Topics:

Risk Management and QA for the Lone Wolf

  • August 15, 2006
  • By Mike Gunderloy
  • Send Email »
  • More Articles »

If you look around, you can find a lot of advice on managing risk and keeping code quality high in software projects. But there's a catch for some of us: the vast majority of this advice is aimed at developers, managers, and testers working in medium or large organizations. When your staff consists of one-third management and architects, one-third developers, and one-third testers, you can make some assumptions about workflow and division of labor. But those assumptions won't hold true when you're working for a very small company. In the ultimate case - where you are the entire software department of a small company, or even a one-man micro-ISV - you're forced to handle your own risks and quality. If you're in that situation, read on for some ideas.

Raising the Quality Bar

So you're cranking along, in the zone, writing great code. Yup, we all do that. Alas, no matter how great a coder you are, the reality is that you probably don't write absolutely perfect code. If you plan to ship this code to someone else to use (say, a client or a customer), you need to figure out how to keep the code quality high. What can you do that won't distract you too much from the coding focus?

No matter how tempted you are to assume you know what you're doing, avoid the temptation to dive right in and start writing code without thinking. Any serious project should have a list of requirements, and every line of code should contribute to fulfilling those requirements. If you don't know what your application is supposed to do, how will you know when you're done? If your IDE lets you maintain a to-do list, that's a good place to do simple requirements tracking. Alternatively, you may want to use a task management or bug-tracking application for this purpose.

Use the testing tools built in to your IDE. These days, just about every IDE will let you create and execute unit tests as you're coding with minimal effort. Automated unit tests won't catch everything, but if you get in the habit of writing them as you go along you'll end up with an excellent "smoke testing" suite: the tests that tell you if the code is absolutely on fire with smoke pouring out of the windows. This is a good starting point for more serious quality control.

Speaking of bug-tracking, do it. No excuses. There are several good free bug-tracking systems on the market these days, and others that offer free licenses for a single user, as well as a plethora of commercial alternatives. When you discover something wrong with your code, track it. When you think of something that might go wrong with future code, or a feature that still needs to be implemented, track that too. The more things you get down in a database somewhere, the fewer distractions you will have cluttering your mind. This means better code and less chance of things falling through the cracks.

Remember that unit-testing doesn't catch everything. Test-driven development advocates will tell you otherwise, but I'm skeptical that even great tests will catch all possible emergent and interactive behavior. Set aside some time to just play with the application. Bang on it. Try absurd input. Try to break it. Remember that your users won't read the manual or put in perfect data every time. During testing, you shouldn't either.

If at all possible, get someone else to test your application. This is the single best thing you can do as a lone wolf: other testers won't have your blind spots. Perhaps you can trade testing time with another developer in another small company, or convince your significant other that a night on the town is worth a few hours of pretending to appreciate your development skills. If you simply must do your own testing, try to set code aside for a few days between writing it and testing it, so you'll have a chance to forget exactly how it works. This increases your chance of doing something stupid and so breaking things. (And remember, when you're in testing mode, breaking things is good.)

Widening Your Focus

Keeping your code quality high is important - but if that's all you're worried about, you're missing the big picture. There are many things that can get in the way between a great idea and shipping software. If you're a lone wolf, any one of these risks, from a tool vendor going out of business to an inability to solve some technical problem, can completely destroy your business. Dealing with these risks is the job of risk management.

If you've never had to do any risk management, your first impulse might be to just worry (or hide). But in fact, you can be much more systematic than that. It's convenient to break risk management up into two steps: risk assessment and risk control.

Risk Assessment

The first step in risk management is simply to understand the risks to your project. Probably the easiest way to do this is to just brainstorm a list of all the things that could go badly wrong between now and the delivery of working software to your customer. Consider four types of serious risks:

  • Those that could destroy the project entirely.
  • Those that could have a substantial negative impact on cost.
  • Those that could have a substantial negative impact on schedule.
  • Those that could have a substantial negative impact on quality.

I recommend developing your initial list by brainstorming - that is, don't censor yourself, but write down every risk that pops into your mind. You'll have a chance to rate the risks soon enough, but you can't rate a risk that you don't think of. On the other hand, try to be at least moderately realistic. It's probably not worth including asteroid strikes and alien invasions on your list of risks for a software project.

When you've come up with as complete a list of risks as possible, you may feel overwhelmed. It's not unusual to have twenty, thirty, or fifty real threats to the successful completion of a modestly-sized software project, from vendors going out of business to hardware failure to inability to code critical sections with sufficient performance. Don't panic. It's not likely that all of the risks are equally important, so the next step is to come up with a numeric ranking of risks so you know what you should really worry about (and control).

My own preferred method for ranking is to assign two numbers to each risk: a probability and a cost. You can express the cost in the amount of money you'll lose if the risk comes to pass, or the amount of schedule slip you'll be forced to take, so long as you use the same units for each risk. Will these numbers be perfectly accurate? Probably not, but if you're an experienced developer it's likely that they'll be relatively accurate, and that's all that matters. That is, a risk that you rate at 10% will be roughly twice as likely to happen as one that you rate at 5%, and a 4-week-slip risk will be roughly twice as drastic as a 2-week-slip risk.

Now multiply the probability times the cost to get the expected impact of each risk, and sort the risks by impact. Focus on the 3, or 5, or 10 risks at the top of the list. Figure 1 shows what this technique looks like in Excel.

Evaluating risk impact

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date