July 15, 2011
Working productively with a group of people of varying backgrounds, skills and motives requires a mapping of the human landscape. If you have worked successfully on international standards and specifications, you will necessarily have, perhaps unconsciously, developed a Taxonomy of Bozos.
Gender note: I’m using “he” as a shorthand for a bozo of any gender.
- Characteristics: talks about his transcendent skill, talent and accomplishments but never proposes anything.
- Strategy: ignore him.
- Characteristics: makes an unworkable proposal and is unable to implement it. Does not understand why it is rejected and keeps trying again. And again. And again.
- Strategy: ignore him aggressively. Unless he is your manager; then you must leave the building immediately and seek new employment.
- Characteristics: makes an unworkable proposal and may be able to fix it and implement it. But he is too lazy to incorporate the feedback and fix the proposal.
- Strategy: offer feedback until he lies down and goes to sleep.
- Characteristics: makes a workable proposal and is able to implement it but wants somebody else to do the work.
- Strategy: cut a deal: help him implement his proposal if he supports your proposal.
- Characteristics: initially makes an unworkable proposal but is able to learn and incorporate feedback to eventually make a workable proposal.
- Strategy: offer constructive feedback until a workable proposal is reached.
- Characteristics: makes a workable proposal and is able and willing to implement it.
- Strategy: find common ground and form an alliance to combat lower lifeforms.
There’s a bozo born every minute. Learn to deal with them. If you have encountered a type of bozo not mentioned here, give me feedback. I will incorporate it.
July 12, 2011
Defects are forever. No matter how good you are, your code will have defects. Learn to live with them.
- Use code analysis tools: Findbugs, Checkstyle, PMD, whatever. Adopt a zero-noise policy: the only acceptable number of warnings is 0. Suppress warnings not important to you.
- Perform code and design reviews.
- Unit test every class and every public method. If you have code that cannot be tested, it is incorrectly designed.
- Measure unit test code coverage. A test may not test what you believe it tests. 90% statement execution coverage is easily attainable.
- Automate your tests. If you cannot automate a test, it is incorrectly designed.
- QA is your friend, not your enemy. Defects are the enemy.
- Catch every exception and log it at ERROR/FATAL level. Monitor the logs.
- Log every successful operation at DEBUG/INFO level. This provides contextual forensic evidence.
- Implement service health checks. You want to be alerted when the heartbeat stops.
- Scope your error handling appropriately. You may not want a 1000-document operation to fail because one document is bad.
- Test your error handling code. You don’t want a minor error to cause a major error because you never tested the catch clause. Error handling code has as many defects as any other kind of code.
If you believe your code has no defects, you are a bozo. Read my upcoming post on the Taxonomy of Bozos to see where you stand.
July 10, 2011
Software engineering is an interesting field. You start your career with visions of elegant algorithms, adoring groupies and start-up riches but eventually you have to face the brutal reality.
- Nothing ever works the first time.
- When something finally works, it always breaks later.
There are two broad categories of organizational responses to this grim reality.
- Delusional. Keep looking for the magic silver bullet that will make defects vanish: smarter people, better tools, new design methodology, shinier executive hair.
- Practical. Acknowledge that defects are ultimately caused by human cognitive frailties and learn to prevent, detect and mitigate them as best as you can.
More about practical defect-busting techniques later because now I need to go to the hardware store to buy plumbing supplies and light bulbs. Because everything always breaks.