Where is the dividing line between complete lack of planning and analysis paralysis?

Question

In my very short time working in the programming field, I've seen two extremes:

• Projects where little to no planning was done and thus become maintenence nightmares.
• Projects that are perpetually in the planning stages and don't move from there.

It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?

Answer 1

Initial planning should be roughly O(log n) where n is expected total development time.

If you have to push in a week, sketch something on a napkin. If you have a month, the first day is for initial design. If you have a year, spend a week.

This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).

Answer 2

Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.

If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.

Answer 3

I think it depends on 2 factors:

• The length of the project

  • Is it a 1 week project?
  • Is it a 1 year project?
  • Or somewhere in between?

• The risk of the changes being introduced in the project

  • Are they architectural in nature, potentially affecting a lot of the original code?
  • Or are you simply adding a new feature?

Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.

There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:

The 2 biggest mistakes you can make in a design are:

1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation

Finding the happy medium between these 2 is the key to successful design and planning.

Answer 4

In my own personal experience, I have found that 'decisions' are my bottle neck.

If this is the case, then :

1. List all your design options
2. Pick an option(s) (pick a few if you can't decide on one)
3. List the risks of the best option(s)
4. For each risk, brainstorm a solution, then design a conclusive proof of concept and write it.
5. If your proof of concepts proves it will NOT work, then toss that option, and pick another one.

A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)

If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.

And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.

Answer 5

Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:

• how much detail can you actually get from any user/sponsor and from this specific group
• how much detail does your current team need (technical/business specific skill levels)
• how open are your sponsors/users in helping during the development (how agile of a team do you have - does it include the sponsor/user?)
• how good are you are identifying gaps

A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).

The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)