Exception Handling in Software Development
Exceptions to the process should be reserved for exceptional circumstances.
This basic principle came up during a discussion of Crunch Mode. “Crunch Mode” is a hip way to say Death March
, only you make it sound like it’s not so bad because it only happens for a short time at the end of a project, and it’s a temporary phenomenon just to tide us over until things return to normal. In other words, Crunch Mode is an exception to the way things are normally done in response to exceptionally tight deadlines.
Or is it?Exception handling
I have encountered developers who say “I know this isn’t the right way to do things, but this is an exception” to explain why they are not writing unit tests, refactoring problem code, or any of a number of other practices that they assure me are the right way to write software. Yes, they know the overall value of certain practices. And they understand that the rot they are introducing to the code—like technical debt—is dangerous and expensive to carry. Not just for “future generations of maintenance programmers,” but for the current team on the current milestone. But this is an exception, damn it!
My first question is always how often this has happened in the past. Were they doing this last week? Last milestone? Last project? If the answer is yes
(and sadly for me, it has been yes far often than no), then my next job is to stop them from using this excuse. If doing things “The wrong way” is common practice on your team, it isn’t exceptional: It’s business as usual
. And that means you have to change or ‘fess up, jut your chin out, and boldly proclaim that you don’t need no stinkin’ unit tests.
Exceptional behaviour is certainly possible and might be the right thing to do under exceptional circumstances. But there are two tests for exceptional circumstances you can apply: First, if they happen frequently, they aren’t exceptions: The way you handle them is your business as usual.
Second, if they can be predicted in advance, they aren’t exceptions either.Managing exceptions with your crystal ball
I know for a fact that stake holders want things that aren’t in the telephone book of requirements. I know for a fact that no matter how many rspecs and unit tests I write, handing my software to someone else will uncover bugs. H*ck, I might discover bugs just deploying my software on another system, and I think it’s an immutable law of software that the more important the person viewing a demo, the more embarrassing the bugs will be.
Critical Chain is an amazing book. The narrative form—a novella detailing a technical project team and their search for a way to manage an uncertain process—highlights the ways that Critical Chain Project Management handles risks and uncertainty and makes it visible where you can manage it in advance.
The section on estimating tasks alone is priceless, and I can tell you that the book gave me a vocabulary and a process for effectively negotiating dates and deliverables with my managers.
I cannot tell you with a straight face that any of these “unplanned things” require exceptional behaviour on my part. I may not know exactly which bug will arise, but I know statistically that bugs happen, that requirements come into focus, and that estimates are just estimates. I do not say to my boss, “I had no idea they wanted a view for this behaviour, I had no idea this other thing wouldn’t work as expected, therefore we need to finish the work without testing.”
I can—and do—expect these things to happen, and therefore I can—and must—plan for them.
Of course, if you fail to manage appropriately, or fail to convince your team that you ought to manage appropriately, then you will find yourself doing things “The wrong way.” But you cannot blame the circumstances, you must blame the choices your team made (or neglected to make) when you first planned your development. You must say, “We chose
this course of action with our eyes wide open back on such-and-such a date.”
I’ve been talking about coding here, but I usually think about team management as the goats. When people are burning out in a Death March at the end of the project, am I to believe that the manager “had no choice, the client was unreasonable?” Let me see. How do all of the projects you manage go? Are they all like this? Must I look at the second test, whether you could have predicted that this client would behave like every other client?
Managing projects means either endorsing and advocating things like Death Marches or it means predicting the circumstances that lead to them and making decisions in advance
that avoid them.Captain Crunch
Crunch Time can be a conscious decision. But please, show me where you wrote “overtime” in the plan at the start of the project. Show me how you planned to complete the high value, must do well features first, leaving the ones that could be incomplete and buggy for the end when people would be working without sleep.
If you fail to plan for Crunch Time, you are not managing your project properly. For example, the traditional model of project management had the software become “feature complete” first, and then Crunch Time would inevitably occur during a bug fixing phase. The problem with this is that the team was now painted into a corner where you could not manage the process. Sure, you could decide which bugs to fix, and therefore you had some ability to decide which features were more important than others, but you could only manage the buggy features.
If doing things “The wrong way” is common practice on your team, it isn’t exceptional: It’s business as usual.
If something was of lower value but was working properly, you cannot go back and do a buggy job of it in half the time so that the developer would be freed up to fix bugs on something important. Managers knew this, of course, which is why they often whipped developers to complete their work in haste early in the project. Paradoxically, this made it easier to manage priorities in a traditional model.
The agile model addresses the issue of managing Crunch Time by doing high value activities first, so that when Crunch Time comes around, you only have low value items. There is no need to whine that you have no choice because a critical feature needs to be ready on Monday. And if you discover something entirely new and unforeseen to do for Monday, you know that it can leapfrog the other items in the backlog because they aren’t that important.
Does agile always eliminate Crunch Time? No, nothing involving humans and free choice always does what you expect. But it is an example of a model where you predict the “exceptional circumstances” and prepare for them. There are other ways to predict exceptional circumstances and prepare for them, of course. The point is that the ends of milestones and projects are known to be difficult and challenging and you need to have a plan from day zero.
And that is the point of managing software development, whether you are managing your behaviour as a developer, managing a team, managing stake holder expectations, or managing a product: it’s your job to expect and plan for these things so that the only time you are “making exceptions” is when the circumstances are truly exceptional, when rare and unforeseeable opportunities arise.
This essay was provoked (in a good way!) by James Golick’s Crunch Mode Paradox: Turning Superstars Average.