When do you know a project smells

I was reviewing a “next generation X” project that has been there for many years. The way it goes, the project will probably still be there when I retire.

I’ve seen many docs from different lead engineers who were assigned to this project at different periods: 1-pager, 2-pager, 6-pager … the irony is, I can’t find a single line of code.

“Why didn’t we write some prototypes to validate the design proposals?” I asked.

“Well, the hardware was not ready yet and we could not agree on what hardware platform to be used for next generation X.”, the poor project manager answered. He took over the project a few months ago. I couldn’t blame him.

“Isn’t this the definition of Analysis Paralysis?” I sighed.

Over the years I built some intuitions of detecting smelly projects.

They usually fall into anti-patterns:

1. Project without customer or stakeholder, no real requirement, therefore without meaningful value to anyone. Believe or not, software industry has many bullsh*t projects that deliver no real values - a way to keep people busy I guess. I often ask my project leads: “name one concrete person that will be delighted if you complete the project. If you can’t find even one person, well don’t waste your time.”

2. Project with too many stakeholders, too many requirements that are often conflicting each other. We go into endless discussions, endless meetings that go nowhere other than the conclusion “let’s have another meeting.” People come to these meetings to get visibility, rather than solving a real problem.

3. Project that has no design, no plan, and usually no deadline. I am not a big fan of very detailed design or project plan. But “plans are nothing, planning is everything!” As Dwight D. Eisenhower once said.

4. Project that has too much design, too many discussions, mountain of documents, but no code, no prototype, no Minimum Viable Product (MVP). In this situation, delivering something is infinitely better than delivering nothing. Divide the problem into smaller ones, split what can be decided now from what need more discussions later, start small and iterate, and code the components that need to be there no matter what.

5. Project that cannot give any sprint demos. If a project cannot provide demos for consecutive sprints, it is usually a sign the project is off track.

6. Projects that rely on a shining new technology for success, rather than careful planning and disciplined executions. How many times we’ve seen comments like “if only we could rewrite the application in programming language X or database Y (often a NoSQL db jargon), all the problems will be solved.” Well, I committed such sins in my career a few times. I’ve seen well intentioned effort to rewrite large Perl applications into Java, which became just Perl programming in Java grammars. Now we have a new problem!

…

What are your project management anti patterns?