Living for Hope in Fear of the F Bomb
I remember years ago at one of the local consulting gigs I was on they held a weekly developer meeting. At the time, I was there temporarily in transition to another gig. The senior developers that worked for the company conducted random code reviews of the consultant's work. At the time there were about 5 company developers and probably about 7 or 8 consultants. We were working on multiple projects.
The first meeting I attended they started to list off the things they found wrong in the code. On about the 5th item, I asked if they were going to tell where that code was located so we could figure out who had been making the mistakes.
They said it was against their management style to embarrass people. No matter how hard I tried to convince them that if I didn't know I made a mistake, I would not be able to stop doing it, they refused to tell what code they were referring too. Every week they listed the same mistakes over and over again.
The F Bomb I am referring to is Failure. Most environments I have been in, failure is always reported as a perceived success. I find it so hard to comprehend never failing, because then you never get to the really important lessons learned. Sure every project has some degree of lessons learned, but a perceived success will not bring to light the lessons learned that are needed to bring about a success the next time.
The following is from page 42 of the book Emergent Design:
I had left and returned for round two at the company I mentioned above. They were desperately trying to deliver a project that was months overdue and tons over budget. I pitched in and helped out. After a few months of 70 - 75 hour weeks, we delivered.
I came in the next week to an invitation to an all day celebration party. The project was about 9 months late, it was budgeted for 1 million dollars, and the company spent 1.75 million developing it and got paid nothing towards the $750,000 lost. In truth, I came in expecting half of the company team's cubes to be empty, or at least getting to help them carry their belongings out the door. Needless to say the company shrunk from about 160 to about 30 people over the next year as it repeated the same process over and over and over again.
… and so began an insanity I had "hoped" I would see die with the dot-com boom crash. Years later, I have accumulated many more of the same types of stories in my story tool belt. Next week I will add a few more… people seem to love to hope...
The first meeting I attended they started to list off the things they found wrong in the code. On about the 5th item, I asked if they were going to tell where that code was located so we could figure out who had been making the mistakes.
They said it was against their management style to embarrass people. No matter how hard I tried to convince them that if I didn't know I made a mistake, I would not be able to stop doing it, they refused to tell what code they were referring too. Every week they listed the same mistakes over and over again.
The F Bomb I am referring to is Failure. Most environments I have been in, failure is always reported as a perceived success. I find it so hard to comprehend never failing, because then you never get to the really important lessons learned. Sure every project has some degree of lessons learned, but a perceived success will not bring to light the lessons learned that are needed to bring about a success the next time.
The following is from page 42 of the book Emergent Design:
Giving Up Hope Of course, one reason we have not changed the way we do things is because most of us have assumed the problem is not the process, but ourselves. In other words, we have believed that the reason the waterfall process does not succeed very often is that we are not doing it right. Software developers have often been thought of as arrogant. I disagree; I think most are very self-questioning and tend to lack confidence. This can sometimes come off as arrogance, but in general, self-assured people don't have to brag. Lacking any defined standards, software developers have traditionally had no way to determine, for themselves, if they were really good at their jobs. Without any notion of what makes a good developer, we live and die by our latest success or failure. This lack of a set of standards is part of what has kept us from becoming the profession we should be, in my opinion. So, because we tend to worry that the failures in our projects stem from our own faults, we do not suspect that the problem might be the methodology itself. Einstein said it: "Insanity is doing the same thing over and over again and expecting a different result." I think we have been a little bit nuts. Well, maybe not nuts. Maybe just hopeful. Think back to your high school mythology class and the story of Pandora's Box. Pandora, the myth goes, opened a box and unwittingly released all the evils of the world. The last thing that emerged from the box was hope. When I was a kid, upon hearing this tale, I thought "Awwwwww. Well, at least we have hope!" No, no. That is not the point. Instead, the point is that hope is evil. As long as we hope that this time we will get the requirements right, and stable, then we will keep doing things the way we always have. If we hold out the hope that this time we will be able to write code without bugs, then we'll keep writing it as we always have. The hope that this time we will be on time, be on budget, just be better will keep us from changing what we do. We give out T-shirts at our courses with cartoons and pithy phrases on them, and by far my favorite shirt says: "I feel so much better since I gave up hope." |
I had left and returned for round two at the company I mentioned above. They were desperately trying to deliver a project that was months overdue and tons over budget. I pitched in and helped out. After a few months of 70 - 75 hour weeks, we delivered.
I came in the next week to an invitation to an all day celebration party. The project was about 9 months late, it was budgeted for 1 million dollars, and the company spent 1.75 million developing it and got paid nothing towards the $750,000 lost. In truth, I came in expecting half of the company team's cubes to be empty, or at least getting to help them carry their belongings out the door. Needless to say the company shrunk from about 160 to about 30 people over the next year as it repeated the same process over and over and over again.
… and so began an insanity I had "hoped" I would see die with the dot-com boom crash. Years later, I have accumulated many more of the same types of stories in my story tool belt. Next week I will add a few more… people seem to love to hope...
0 Comments:
Post a Comment
<< Home