anti-pattern

I Like this. Have seen most of them (and probably been guilty of a few a while ago…)

I suggested a couple of others…

How about the ‘Stealth Bomber’. This is probably an extreme extension of the Hidden Dependency. I’ve seen a few tests that would simply ‘never’ fail when run interactively or debugged, or during a full test run in the day. When a supposed ‘fix’ was implemented it would even fool the developer into feeling pleased with themselves by passing for a day or two before bombing again in an overnight run. The logic wouldn’t show anything untoward, and it continued to bomb every few days without warning or trace of ‘why’. More than likely a group of no-no’s of execution sequence-dependent, date/time-dependent, database-dependent, context-dependent etc.

There’s probably another variation – maybe the ‘Blue Moon’. A test that’s specifically dependent on the current date, and fails as a result of things like public holidays, leap years, weekends, 5 week months etc. This is again most likely guilty of not setting up its own data.

I was gaining much (renewed) amusement through anti-patterns the other day when I took a look at Scott’s blog on ‘real world’ development approaches, and subsequently dug a bit further on management and development anti-patterns on Wikipedia.

It then struck me that although these are absolute classics that we’ve all seen (management ones ‘all the time’), I probably don’t know any developer (including myself) that could truly say they’ve never been guilty of at least one of these. I’d go further and say that some of these anti-patterns can form an effective apprenticeship for software development, as you really need to know what not to do as much as what to do in regards to design and coding approaches.