Fix The Process
Fix The ProcessOn most projects, development conforms to some set of project guidelines. The guidelines are intended to prevent developers from commit various types of errors. However, errors may occur that are not addressed by the process guidelines.
Therefore: When problems arise, do not simply fix them. Fix the process that allowed them to happen. This prevents errors of the same type from occurring in the future.
An additional effect of this action is that you no longer BlameThePeople?. It is the fault of the process that they were able to introduce errors.
A very good account of FixTheProcess in action can be found in the article TheyWriteTheRightStuff.
FixTheProcess is much easier said than done. If you're JustaProgrammer, and your organization is like most, it will be next to impossible to FixTheProcess. Not only that, you might jeopardize your potential for advancement by rocking the boat (c.f. SentienceConsideredHarmful). This pattern ignores politics, and I think that qualifies it as an AntiPattern. That being said, sometimes it is possible, and in those cases, it would be a pattern. However, the text above does not provide enough context to qualify it, IMHO.
The question of how you make changes is appropriate to all ProcessPatterns, not just this one. Some people may not be able to apply this pattern, true. But that doesn't reflect on the validity of the pattern.
When I said AntiPattern, I meant it in the strict sense of the word. It is a pattern that usually backfires. It makes logical sense to FixTheProcess, but if you try to apply it without having done your homework, you're likely to damage your career. Or perhaps we should call the AntiPattern RockTheBoat? or maybe RockingTheBoat?. My main suggestion for this page is to supply more context and a more thorough description of how to do it, when to do it, and what pitfalls can occur. I don't think this page, as it stands, is a valid pattern, because it is missing some very important pieces of the pattern puzzle. Add in those pieces and then it will be a valid pattern.
Another thing that's missing is three examples of this working. Otherwise, it's just a daydream.
FixTheProcess is much easier said than done.
Yes, for the reason given above and for another reason. Errors are sometimes the result not of a broken process but of the introduction of some random input that goes outside the bounds of normal process capability. In this case, FixTheProcess is exactly what you don't want to do, because you're leaving it broken for some normal cases. When systems are not well enough understood, inept managment falls into this trap of thrashing with the system because it feels it has to react to every error with a "fix".
Yes, something similar is explained on the IdiotProofProcess AntiPattern page.
If you're JustaProgrammer, and your organization is like most, it will be next to impossible to FixTheProcess.
Because you lack the legitimate authority? That's true at the group level, but not at the personal level. You always have the option of fixing your own process, and that fix may not look anything like the fix that is apparently needed at the group level. Which is interesting, because if everyone did this, something interesting might emerge at the group level.
For example, you might step slightly outside the group process and ask a peer to privately review your work. Another version of this would be if your group process does not embrace PairProgramming, you might still ask a peer to assist you as you write some code. In fact, as a personal process change, you might decide to always seek a partner to write code with, even if one will not always be forthcoming. You can still adhere to that process.
Yes, that's it! Lacking OfficialAuthority? is one condition that will cause FixTheProcess to be an AntiPattern. Thank you for pinning down the words that I couldn't.
It is possible to FixYourOwnProcess?, but what if the problem is really the organization's process. A friend of mine, who works at MicroSoft, told me very recently about an incident where he followed the check-in procedure by the book and still had problems when a) people were not effectively notified, b) people did not pay attention to the existing notification, and c) the existing tests did not cover some esoteric cases (specifically dealing with internationalization). It was not my friend's official responsibility (by the book) to handle these situations, and he also did not have the tools or authority to FixTheProcess on his own. He had no way of knowing who had not received proper notification, and no way of knowing who had failed to read the notification, and no way of knowing that the tests did not properly cover those esoteric cases. In this case, FixTheProcess would have become BangingYourHeadAgainstTheWall?.
I think the error here is in thinking that "the problem is really the organization's process". If your friend had a problem, then the problem is the pain he feels. He needs a process to target that specific pain. The organization has a process that may target some of it, but leave an unacceptable residue. Your friend has the option of using the organization's process and supplementing it with his own, or ignoring the organization and designing his own solution from scratch. A mind clever enough to program is clever enough to figure out which parts of a process can be reused. This takes work, however, and we are expecting the organization process to give us stuff for free. I suspect that's the root of the problem.
Overgeneralization is another root cause in these cases. I'll bet your friend doesn't need "everyone" notified of his changes, and I'll bet he pretty much knows who needs to know and who doesn't. No need to headbang here; just drop a note to your co-workers. If he doesn't know who they are, then that fact in itself suggests to me a profound chance for personal process improvement. -- Walden
No, it really is Microsoft's process that was the problem because it was wasting a lot of its employees' time. This is Microsoft, and he's working on a large product, there really is no practical way to know everyone, to know who needs notification, or to walk around and make friends with everyone who might possibly be working on the project. To give you a sense of the scope, the check-in he needed to do affected three major Microsoft products. Give me the benefit of the doubt here. If Microsoft had a better process, then some of these things might have been possible or even completely avoidable. However, it is not in his realm of control to FixTheProcess. That is the point of the story.
You have the benefit of the doubt. It stinks when processes don't work the way we would like them to, wasting people's time. I suppose in this case there is a manager somewhere who is responsible for the process in question. In other words, the guy with the apparent power isn't using it well. What I'm wondering right now is, what's the programmer's best response in a situation like this? -- Walden
From personal experience, if the programmer responded by trying to FixTheProcess (without the official authority to do so), then this would back-fire. It takes a special kind of organization to respond to FixTheProcess-style criticism without the usual reactions to RockingTheBoat?. They are exceptions to the rule. The programmer needs to be more subtle. If the process you are trying to adopt is XP, then you might look to AdoptingXpPatternLanguage for some (mostly ProtoPattern) examples of how this might be done. One example that might fit the above Microsoft example is FirstCreateTheMailbox.
Fixing an existing process and adopting a whole new one (XP) are two very different things. Should a programmer be subtle about things that impede his productivity? Polite, yes, but I think subtle, no. I've experimented in the past with subtle messages. They are appealing to the neophyte who seeks to get results while avoiding conflict, but to others he comes across as manipulative and game-playing. Something on the order of CriticizeBluntly seems more in order. But my question remains unanswered in the concrete: What is his best response to the situation at hand? -- Walden
Are they very different? I don't think so. They both are attempts to influence others' behaviours and attitudes; and often these are held very tightly by some groups. By the way, CriticizeBluntly is exactly what alienated me at my previous company (see below); I would suggest avoiding it at all costs as a rule of thumb.
I don't think there is a "best response". FixTheProcess on its own is a naive strategy. In order for it to be successful, one needs to have a fairly complete understanding of how to influence people. Then, using that knowledge, one chooses the strategy appropriate to the situation. Different people respond differently to attempts at influencing their behaviour. Witness CostinCozianu. He responds well to CriticizeBluntly; most people don't.
There is significant difference between fixing something and adopting something else. The difference is that when you fix something, you in essence keep it. You can examine the psychology of that without further prompting. Somehow, this page drifted from a simple "FixTheProcess" focus to a more problematic "FixTheOrganizationsProcess?". How and why did that happen? I've talked with countless programmers who whine about the way things are done. When we get close to the subject of what a particular programmer could do on his/her own to make improvement, the subject suddenly turns to "The whole organization would have to change." Uh-uh, it wouldn't. So what's going on here? -- WaldenMathews
Okay, this and Jim's comments below are shedding some light on the miscommunication. When I hear the words 'the process', I hear, 'the (hopefully) formalized methods by which things get done in the organization, from who's in charge of what to how do you do it'. In several organizations I've seen, a lot of people have a lot of stake in the process because it protects them or gives them power. They don't want to change it because it would disturb their security. Often they don't care about how effectively things are getting done as long as they are not in danger of losing their cushy jobs. Meanwhile, the whole company suffers. The people who have the power to change the process are exactly the people who don't want to change it. Any naive attempts to do so (without a good plan) will be viewed as RockingTheBoat? and will actually be counter-productive. Does this explain why I was reluctant to call FixTheProcess a pattern? I understand what Jim means below in his examples; perhaps there is another name that could be used? --AnonymousDonor
What if we used FixYourProcess?? Here's some revised wording:
We all have a process that we follow when doing tasks. Sometimes these processes are formalized; sometimes they're not. When someone makes a mistake, they're following a process. If the task is common, that process could be used again.
Therefore, fix the process. Identify how the process could be changed so that the mistake can no longer be made.
You may not have the political power needed to change other people's processes. Therefore, fix your own processes first.
(Well, that's the general idea. I'm not particularly happy with the way it turned out. I tried too hard to fit it into pattern form. --JimLittle)
HowToFixTheProcess:
Maybe it's hard to fix the process in a large company like Micro$oft, but is it so difficult in a smaller company with around 100 employees?
Some process fixes I have been able to initiate (I'm not saying that these fixes are yet complete, just that they are progressing):
I'm not trying to be a hard-ass. I agree with the concept of FixTheProcess, but this page, as it stands, does not describe a pattern. The above section "How to fix the process", does not describe how, it describes what.
How? In order:
I used to work at a company of less than 40 people. I tried to FixTheProcess, but I did it in the wrong way. I tried to appeal to logic, I wrote up recommendations, I tried doing things my way, I got into arguments. This did not work. In fact, when the company downsized, I was the first out the door. The irony is that now they've got an "experienced" manager in there now who is basically bringing around the same changes I had been advocating for 2 years prior to his arrival.
I used to work for a company with 20 people as a tester. I rapidly discovered that people didn't like me coming to them with new bugs I had found, but they did like it when I came with new bugs and the corrected code. The underlying issue was whether I was perceived to be making their life easier or not. I'd suggest that the crucial bit with your recommendations not 'taking' was that the people receiving them felt that they would have to do more work to get them in place. Also you had no back up from people around you. In the situation described above, work colleagues agreed on the needed changes before they started being formalised, and when we went over to the UK, within development there was full agreement as to the basics of what was needed.
It's not enough to tell someone to FixTheProcess. It's not enough to try to FixTheProcess. There are good ways of doing it, and there are bad ways of doing it. It can either be a pattern or an anti-pattern, depending on how it is done. In order for this page to qualify as describing a pattern, it should explore these issues thoroughly.
Exactly. What you're describing is a change project. There's a lot already written about that, mostly by "management" types. As often happens on the Wiki, this page seems to be re-inventing it (rather than referring to it), seemingly because there's a belief that nothing that managers (practioners and theorists) do could possibly be of interest. If you want a really interesting discussion of why attempts at change may fail (initially or later), I suggest TheDanceOfChange.
Yes, I'm whining.
This ProtoPattern was originally named "BlameTheProcess?." Using the word "Fix" seems to have raised some feelings of bitterness. (Perhaps because some organizations doesn't give their programmers enough respect or power?) The original point was identifying and fixing root causes, not ChangeYourOrganization. How can we get this page back on topic?
Now that I think about it, "The Process" may be the words to blame here. The "process" is everything that the team does, big and small. Hopefully, the things that need fixing are the little things. For example, perhaps a deployment went awry. FixTheProcess by creating a automated deployment script. IntegrationHell? FixTheProcess by introducing a daily build. Accidently smoked the production database? FixTheProcess by making it read-only to programmers and provide a mirror for testing.
I would hope that everyday programmers could make these sorts of fixes.
-- JimLittle
Jim, I think your suggestion of FixYourProcess? is just the ticket, and "the process" is a problem because it implies (to some) the organization's process, i.e., something beyond your sphere of control, in Covey terms. I see your original idea as a combination of "fix versus blame" and "fix process versus fix individual errors". These seem sufficient subject matter on their own without extending the subject into the broad area of change artistry in the large. However, when you substitute the word "your", you now imply an additional message, which is to work within your sphere of influence to make changes that matter to you, aware (but not too aware) that beneficial changes at the organizational level may emerge from a widespread "fix your own process" attitude among developers. -- WaldenMathews
Yes, I like FixYourProcess?. I still agree with FixTheProcess as a possible pattern (or maybe a refactoring?), but it needs more substantiation (when and how to do it) than FixYourProcess?. FixYourProcess? is what I did when I failed to FixTheProcess of the company. It turned out to be a very valuable move, and relieved some of the frustration of failing to FixTheProcess. Specifically, when I saw my ideas (well, actually Kent's ideas) working for me, I knew I was on the right track and I no longer had those doubts, "What if I'm wrong and they're right? What if these changes really won't work in this company?"
I surmise the FixYourProcess? and FixOurProcess? are the only ones that really exist, while FixTheirProcess? is a fantasy held by many of us, and FixTheProcess is underspecified enough to be construed as any of the above. -- WaldenMathews
EditText of this page
(last edited February 16, 2005)
or FindPage with title or text search