February 4, 2012
If an extraterrestrial attempted to determine what a typical software engineer work day contains, solely based on job interviews, he might conjecture the following.
- Brain-storming to find solutions to business problems involving burning ropes, ping pong balls and manhole covers.
- Fermi question estimation workshop.
- Big O party.
- Programming language syntax quiz hour.
- Algorithm rote memorization session. Bonus awarded for the largest number of sorting algorithms memorized.
- Whiteboard coding. One team member writes code on the whiteboard while the rest of the team observes in a casually intimidating manner.
- Introspection workshop. Bonus awarded for the most creative presentation of “I’m a perfectionist” and “I work too hard” as a weakness.
- Code talk.
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.