JavaEnterprise JavaRisk Management and QA for the Lone Wolf

Risk Management and QA for the Lone Wolf

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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

Risk Control

Now that you know what to worry about, can you do anything besides chew
your fingernails? Fortunately, the answer to that question is “yes.” This
is where risk control comes in.

There really isn’t any magic to risk control. Basically, it’s just a
method for systematically thinking about how you’ll deal with risks.
Notice that I didn’t say “react to risks.” The idea of risk control is to
avoid being in emergency mode, reacting to risks when they pop up as
though you’re in a giant game of Whack-A-Mole. By thinking things through
in advance, you can deal with risks in a more optimized fashion.

After identifying the most important risks to your project, take a bit
of time to develop a risk management plan. Choose a reasonable number of
the highest-impact risks, and figure out your management steps for each
risk. Consider these questions:

  • Can you take steps to make sure that the risk never
    materializes?
  • Can you take steps to lower the probability of the risk?
  • Can you take steps to lower the cost of the risk if it does
    materialize?
  • Can you take steps to speed recovery from the risk if it does
    materialize?

For example, if one of your top risks is that a particular control
vendor, whose product you’re using in beta, won’t deliver a shipping
version in time for you to meet your deadline, what can you do? You can’t
eliminate the risk entirely, or lower its probability. But you can lower
the cost and speed recovery by writing your code in a manner that makes it
easy to swap in an alternate control from another vendor, and by having an
alternate vendor in mind. If you’ve planned from the start of the project
to control this risk, you can execute your risk management steps quickly
if, late in the game, you determine that the original control won’t be
available when you need it.

Living With Risk

After you’ve done your risk assessment and developed your risk
management plan, don’t forget about it. As you move forward through a
development project and gather additional information, risks change. You
might implement a tricky section of code (removing it from the risks
list), or run into a serious bug during your testing (raising the spectre
of a new risk). I recommend weekly reviews of your risk management plan at
a regular time in your schedule. For me, mid-day Monday, after I’ve dealt
with the glut of weekend e-mail, works well. Looking over project risks
and thinking about whether there have been any changes serves as a good
transition from paperwork to coding.

If you can keep the quality of your code high and the other risks to
the project under control, you have a much better chance of delivering
working software than the average developer using a random, chaotic
process. None of this requires you to implement heavy amounts of paperwork
or spend a huge chunk of your day doing things other than coding. Instead,
you just need to apply the same discipline you use in writing code to
thinking about the issues surrounding your code. If you try it, you’ll be
glad you did.

About the Author

Mike Gunderloy is the author of over 20 books and numerous articles on
development topics, and the Senior Technology Partner for Adaptive Strategy, a
Washington State consulting firm. When
he’s not writing code, Mike putters in the garden on his farm in eastern
Washington state.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories