Fairly Good (and Staggeringly Bad) Practices
Inspired by fairlygoodpractices.com, informativeworkspace.org and various conversations at XTC I create a poster about Fairly Good Practices for XP Day. The poster showed a some good practices from teams I've worked with or talked to.
- At EasyNet the team have made South Park-style caricatures of all team members. They have laminated versions on the planning board that are used to indicate who is working on which story or is available to help with production issues. The caricatures are also displayed by the Build-o-Matic build server to show who committed the changes being built, who contributed to which version and, occasionally, who broke the build. Ivan has written about that in more detail on his blog.
- At Google the testing group run a "Testing on the Toilet" campaign to help programmers to improve their testing skills. They put posters about testing techniques on the toilet walls and above the urinals!
I left space on the poster board for other delegates to pin their own ideas. Here's what had been pinned by the end of the conference:
- Always identify who wrote a TODO in the TODO comment itself.
- Annotate story cards with a common set of markers when the work for the story has been started, is ready for sign-off and has been signed off.
- At the start of every iteration read all the TODOs and turn them into tasks, delete them or put them in the list of future work. Also skim the future work list and delete items that are no longer needed.
- Connextra used to post the current bug-list on the back of their toilet doors.
- Don't worry about being right all the time, only about being right at the end. P.S. there is no end.
Chris Cottee responded by creating his own ad-hoc poster about Staggeringly Bad Practices seen on real projects. Sadly his poster attracted more contributions than mine even though it started out as one hand-written index card. Here's what was on his board by the end of the conference:
- Keep some regression tests always failing to break up the monotonous green colour.
- Put all your logic in one SQL statement that is hundreds of lines long. [Wimps! I've seen application logic in SQL statements that are tens of thousands of lines long]
- Our supplier ceased documenting their core API because of "lack of resource". They still kept changing it, though.
- Replicate the same data twelve times in four sets of tables and build reconciliation between them.
There's no point in putting code into source control until we know it works in production.
Every time you have a "bad" day drop a practise and get everyone to reestimate everything until people begin rocking back and forth under tables.
We lost the source code and decompiled from production.
- Use production passwords in development because it makes it easier to refresh the databases.
- Don't delete unused code: exclude it from the source fileset in the Ant build file.
Thanks to everyone who contributed... whoever you are.