Process Smells

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

You haven't had a post project review....when the project ended 6 months ago.

Answer 2

• Shipping a prototype - "we'll productize it later"

Answer 3

Some smells I have seen:

• Optimistic management, but they can't pay your salary this month. This is real bad. I left the company in time but it died a few months later.
• Extreme fanatic team building sessions. Focussing on how great the company is. But in the end it all goes down.
• Good new people are laid of because they tried to change the process. Real shame. I have seen some people that really tried to improve the company, but old habits never dies so it often ends in a big desillusion.
• The boss is always right mentality...

There is more but I won't spoil the fun for others.

Answer 4

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! :-)

Answer 5

I suggesting checking out the Organizational section of the wikipedia page on Anti-Patterns. The I've had to deal with are 'Crisis mode' and the 'on-the-fly estimates' you mentioned.

Answer 6

One smell I have a real problem with (because I work with it): Not ditching tools, dev software, methodologies, or anything else that doesn't work.

Many times, there is one (or more than one) piece of software that clearly, blatantly, doesn't work and likely interferes with the development process, but which a project manager simply refuses to replace/upgrade "because it would cost too much {time, money, whatever} to replace."

Edit: This also extends to machines and other infrastructure too (examples: a build server that takes an hour to do a two-minute build, or a version control system - ahem CVS - that takes 15 minutes to find out whether there have been any updates on a 50MB source tree).

Answer 7

• Back Dating - being given an end date and then told what needs to get done
• Inverse QA Coverage - QA focuses on the non-essential items (because that's all they know how to test)
• Environmental Alignment Issues - the various environments (Dev, Test, Staging, Production) are not in sync for code and data - therefore any testing prior to production is invalid
• Delivery Date Detachment - no one believes in the end date because: it was made up to begin with and 100% of prior projects never met their delivery dates
• Old Grumpy Code - old code is feared because there's no desire to refactor
• the evil pm triangle (scope, cost, resources and/or quality) - to adjust the project you need to add people, reduce quality, reduce scope, etc....once a project is in motion, most changes (even reduction in scope) will increase time and cost and reduce quality..once the train tracks are down, it's tough just hanging a left turn

Answer 8

What I call: NIH (Process edition), a.k.a. Choose your own adventure.

Evidence of this:

• you spend endless meetings debugging the process. And refactoring it.
• nothing really gets done, because no one knows what they should be doing.

I guess this is an antipattern, rather than a smell.

Answer 9

Changes to process are made with no thought to timing or current deliverables, then immediately reversed when deliverables turn up late due to instituting new process.

Someone goes on medical leave and the team as a result is behind trying to pick up that person's work as well as their own and when the managers or clients or client sales reps are told things will be delayed as a result, they are only concerned about when things will happen and can you work nights and weekends in the meantime and never even ask about the person with the emergency and how he or she is doing.

When overtime for low level people is expected but the people who want this urgently leave on time and are not availble to answer questions. Or when they make you work overtime to be ready by 8 am and then don't look at it on QA for three more days. Hello I could have done it by then in regular hours.

Delivery of needed files (for data import for example) or information minutes before the due date and then blaming developers when due date is not met.