Mitch Wheat - Treat the cause, not the symptoms!

Darren Neimke posted an interesting question on a situation many developers/managers find themselves in. I’ve quoted it in full below:

You've just joined a new company as a senior developer. During the interview process your role was discussed in depth...

1. Lead a development team
2. Deliver a new application
3. Using state of the art tooling
4. Highly ambitious

You start, and in your first few days you are shown more details of the task at hand. The project plan and delivery timeline were created by the head developer - a person for whom you have a great deal of respect. Internally you are no really about how you will deliver this in such a short space of time.

What do you do next?

Even though Darren posted this over a week ago I thought I would chip in with my 2 cents worth and attempt to answer some of these questions, beginning with a few of my own:

Does point #3, do you mean that there is little experience with a new set of tools? Are these tools stable, well documented, well supported? Are we talking about VS2005 Team System?

Point #4: In what way is the project "Highly Ambitious"? For the customer? For the developers? Does this mean it consists of too much scope in an undoable timeframe? If so, it’s time to start pruning non-essential features.

How would you establish that the existing project delivery plan is realistic?

First thing I would do is take a look at the requirements (hopefully, you have some). Talk to the customer, and make sure you understand what they are trying to achieve; in other words, get an understanding of their target domain and how this software will make their task easier/more productive and what the essential features are (“The high level feature list”). If you are going to sign up for, and be responsible for a project delivery plan, then you should verify that what is being asked is achievable.

“Get the feature list from the customer, and then figure out the requirements you need to implement those features”

Next up, do you have a set of use cases (scenarios) describing the high level processes that the application is supposed to perform? This is a excellent way of determining if the features are all supported and the requirements are complete, or if there are there surprises lurking.

"scenario" is often used interchangably to mean one of the following:

1. a use case
2. a path through a use case
3. an instance of a use case

#2 and #3 are really the same thing. #3 is preferred (more than one scenario occurs when the use case has alternate paths, but these still achieve the main goal of the use case)

Each use case must have:

• clear value to the system
• a well defined start and stop point
• an external initiator

As soon as you have a set of use cases, you can perform textual analysis upon them to figure out candidates for your classes and methods (nouns and verbs). By this point, you should have enough information to break up your application into smaller pieces of functionality, and have a better handle on how much development time is required.

Grant Halliday's comment about working 20 hr days is a little worrying! ;) If any developer is working more than 8 or 9 hours a day, then you have a big problem. Odds are they will be making plenty of mistakes. There is considerable evidence to back this up. A good plan will not force developers to work unproductive hours. Any manager that thinks he will retain the confidence and support of his staff in doing so, is almost certainly mistaken.