The previous questions in The Big Swinging Developer Test referred to specific experience or skills.  Part 1 is about branching and merging in version control.  Part 2 is about creating a one step build.  Part 3 is about build automation and recommends getting some experience with at least 2 different commercial or open source systems.  Part 4 also recommends getting experience with a couple of different systems, but this time for bug tracking.  Part 5 is about refactoring, which also involves having unit testing skills.

Before getting into part 6, I wanted to point out another difference between this test and the one it’s modeled after: The Joel Test: 12 Steps to Better Code.  The main difference is that The Joel Test is used to judge organizations and The Big Swinging Developer Test is used to judge developers.  The difference I wanted to point out, however, is that The Joel Test is used for negative gap analysis where missing something means that you’re in trouble. The Big Swinging Developer test, however, can be used for positive gap analysis where missing something indicates an area where improvement can make you more valuable.  Looking over the past 5 parts it struck me that you can be a fine programmer and good developer without having any of the experience or skills listed.  Add those skills in, however, and you can be an incredibly valuable developer who improves any team or company where you work.  Now, a little about schedules.

The Joel Test:
6. Do you have an up-to-date schedule?

The Big Swinging Developer Test:
6. Do you raise risks that could affect the schedule before they become issues?

This seemingly simple question is actually asking 3 questions at once.  The first is: "Do you know the difference between a risk and an issue?"  A risk is something that may go wrong.  Risks can be mitigated, accepted, or (in some cases) transferred.  An issue is something that has gone wrong, or is going wrong at the moment.  Risks are harder to identify than issues because they involve thinking about what may happen rather than pointing out what’s going on and why it’s bad. 

That brings us to the next question: "Can you identify risks in a project?"  A lot of developers can be given a task list or work breakdown structure and come up with workable estimates.  It takes a special developer, however, to look at the plan and identify that the integration point that they’re dependent on may not be ready in time, or that their team may spend more time than planned supporting the previous release, or that it’s going to be monsoon season in India, where some of their critical resources live. 

The meat of the question, though, is: "Do you have the confidence to raise risks?"  I’ve worked with plenty of developers who report that everything is going swimmingly up until the day that things go supernova.  This is usually preceded by weeks or months of sitting in meetings where another developer is reporting a less rosy, but more realistic, outlook that causes extra risk mitigation work on the part of the project managers or development managers.  Believe me, the weeks or months of being known as "the easy team" are instantly forgotten and replaced by feelings of "why didn’t you say something sooner?" once the jig is up and their risks have turned into issues that have far fewer (and typically less pleasant) options.

Bad developers keep risks to themselves and try, in solitude, to keep them from becoming issues.  Mediocre developers simply get blindsided by issues because they weren’t giving enough attention to the bigger picture.  Big Swinging Developers know what can go wrong, are vocal about it, and give the rest of the project the chance to choose how to deal with risks.