(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Wednesday, February 20, 2008
Exception Handling in Software Development
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 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.
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 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.
Comments on “Exception Handling in Software Development”:
<< Home
I agree with your view on this and your reasoning and we should also recognize that knowledge, which is what your post provides, is the often times the source of change, it is not an active correction mechanism which is what is needed to change the behaviour of people and organizations. Correction mechanisms are feedback mechanisms and the only one that I can think of for addressing this issue, and I have considered this issue on a number of occasions, is to change how people are paid for their work.
Knowledge workers are by in-large salaried employees. This hides the cost of these wasteful practices, as who knows and pays for how much overtime they work, and how much time they take off recovering from these sessions. If, knowledge worker - programmers, were classified as hourly workers, who therefore have to to be paid overtime when they work more than whatever the standard number of work hours are for the jurisdiction they work in. This change would surface the cost of Crunch Mode and also of many other sources of waste. Now organizations can decide do they just accept the cost or do they do something about it.
Norbert
Knowledge workers are by in-large salaried employees. This hides the cost of these wasteful practices, as who knows and pays for how much overtime they work, and how much time they take off recovering from these sessions. If, knowledge worker - programmers, were classified as hourly workers, who therefore have to to be paid overtime when they work more than whatever the standard number of work hours are for the jurisdiction they work in. This change would surface the cost of Crunch Mode and also of many other sources of waste. Now organizations can decide do they just accept the cost or do they do something about it.
Norbert
,----
| 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.
`----
The tacit assumptions here are (1) all activities can be known at the
beginning of a project (2) that the value of all activities are known
at the beginning of a project and (3) that these values do not change
relative to each other. In my experience no project of appreciable
size will exhibit these properties.
| 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.
`----
The tacit assumptions here are (1) all activities can be known at the
beginning of a project (2) that the value of all activities are known
at the beginning of a project and (3) that these values do not change
relative to each other. In my experience no project of appreciable
size will exhibit these properties.
Lee:
These are not my assumptions, nor are they assumptions of agile as I understand it and practise it. Agile embraces those assumptions while classical rejects them.
For example, all agile processes emphasize iterations specifically because not all requirements are known, the values are not known, and the values change as we gain understanding.
The point of the sentence you quote is that if you are constantly obtaining new insight and prioritizing your work within iterations, the amount of work in your backlog that is of the highest value will remain small relative to the work that has already been completed that is of the highest value.
Please do post again if you do not feel that the concepts of iterative development + re-prioritizing work between iterations does not address your concern.
These are not my assumptions, nor are they assumptions of agile as I understand it and practise it. Agile embraces those assumptions while classical rejects them.
For example, all agile processes emphasize iterations specifically because not all requirements are known, the values are not known, and the values change as we gain understanding.
The point of the sentence you quote is that if you are constantly obtaining new insight and prioritizing your work within iterations, the amount of work in your backlog that is of the highest value will remain small relative to the work that has already been completed that is of the highest value.
Please do post again if you do not feel that the concepts of iterative development + re-prioritizing work between iterations does not address your concern.
That's well and good, but not really always possible. Sometimes the work comes with a target date which you cannot negotiate. Lawmakers, for one, are rarely concerned with how much effort it will take for a company systems' to be adapted.
<< Home
