Its Chets Fault

[Extracted from DontBlameJustDo because it feels like it should have its own page]

Recall that on ChryslerComprehensiveCompensation, we have an official person to blame. We have a card from ChetHendrickson, signed, saying "It's my fault". One way you can use this is to say things like "OK, we know it's Chet's fault, but what caused this problem?" It reminds people to keep it light.

Where I have a problem with the no-blame thing is that every program defect I've ever seen was caused by a person, and if we don't drill down to see what that person did, and should have done, we can't improve. So I like to know who did it, and what happened. The C3 team doesn't agree with me on this. Probably I'm wrong. -- RonJeffries

I guess the difference is all in motivation. I can see Ron here as a helpful team leader trying to help the offender be more successful, and that's good. On the other hand, such situations can turn into witch hunts, and that's where ItsChetsFault can give the angry mob enough pause to put the pitchforks back in their barns and go home. -- JasonPettys?

I used to get very upset about the quality of code my colleagues (and myself) wrote.

It was quite a remarkably conflicting experience.

On one hand I would find heaps of hideous examples of code they (and most embarrassingly) myself had written.

And on the other hand I would sit by them from day to day helping them.... and observing that they were ALL pretty good coders honestly trying hard.

Eventually I came to an Epiphany....

Every bit of code written is the Best that the author could do, given his goals, tools, constraints, pressures and knowledge ON THAT DAY.

The goal post shift day to day.

The tools have problems and limitations.

The author has constraints on time, RAM/ROM/MIPS.

He is always under schedule pressure.

And they are all learning new things and better ways every day.

But it was the best the author could do ON THAT DAY.

This doesn't mean that it is the best we can do on THIS DAY.

It does mean we should always be pushing for better tools, looser constraints.

It does mean we must continuously refactor to meet the goals and use the better knowledge of THIS DAY.

We could spend many a happy hour analysing why it made sense on THAT DAY, or we can refactor, and make it the best that can be done on THIS DAY. - JohnCarter