Question

We’re generally familiar with code smells here, but just as damaging if not more so are when the business side of things – as much as it falls within our domain – is going wrong.

As examples, the inverse of anything on the Joel test would be considered a major process smell (i.e. no source control, no testers) but those are obvious ones and the point of ‘smells’ is that they’re subtle and build into something destructive. I’m looking for granularity here.

To start off with here’s a couple (which can be turned into a list as the answers come in)

---

• Writing code before you have a signed contract with the client

• Being asked for on-the-fly estimates (‘just a rough one will do’) for anything which will take more than a day (a few hours?)

• Ancient cargo-cult wisdom prevails (personal example – VisStudio sourcesafe integration is banned)

• You’ve stopped having non-project specific group meetings (or lack any similar forum for discussion)

---

So what are some other process smells, and just how bad are they?

Answer 1

The book ‘Antipatterns‘ by William J. Brown et. al. has a bunch of project-related smells. They aren’t always disasters in progress; mitigating circumstances exist for just about any smell.

The Portland Pattern Repository also has a page on Antipatterns, covering many of the same topics as the ‘Antipatterns’ book. Visit http://c2.com/cgi/wiki?AntiPatternsCatalog and scroll down to ‘Management Antipatterns.’ A few examples:

• Analysis Paralysis – a team of otherwise intelligent and well-meaning analysts enter into a phase of analysis that only ends when the project is cancelled.
• Give Me Estimates Now – a client (or PointyHairedBoss) demands estimates before you have enough data to deliver it. You accept the ‘challenge’ and give out of the head estimates (i.e. guesses). The client/boss then treats the estimate as an iron-clad commitment.
• Ground Hog Day Project – meetings are held which seem to discuss the same things over and over and over again. At the end of said meetings, decisions are made that ‘something must be done.’
• Design By Committee – Given a political environment in which no one person has enough clout to present a design for a system and get it approved, how do you get a design done? Put together a big committee to solve the problem. Let them battle it out amongst themselves and finally take whatever comes out the end.

Collect them all! 🙂