Fog Creek Software
Discussion Board

Software Estimates Early in the LifeCycle ...

Scenerio: THIS IS FICTION.  Please just give you $0.02 …

Let’s say you are a coder at Fog Creek when they are bought by Blogger.  You hear various promises that CityDesk will live on, you will have a job, Fog Creek will contine to operate as an autonomous business unit of Blogger, etc, etc.

Eventually, it gets time to start developing the business plan going forward.  An executive goes to your group and asks for time-lines for the following features:

Integrate CityDesk with Blogger
Port CityDesk to MDE and SQL Server
Port CityDesk to Linux/MySQL
Internationalize CityDesk – move chars to TCHARs
Peachtree small business project
Port Peachtree project to Great Plains
Port Peachtree project to SAP
Port Peachtree project to JD Edwards
Port Peachtree project to BAAN
FogBUGZ/Blogger integration

The PeachTree project your knew about – the idea was that PeachTree users can use citydesk to migrate business to the web.  It also requires partnering with a web hosting service, and integrating with at least one (probably more than one, for purposes of redundancy) e-commerce transaction provider. (“Credit Card Vendor”).  You have a somewhat detailed task list for this item – you’re figuring on 1 man-month to design, 3 man-months to develop and two for a QA phase, figuring on a staff of one coder for the entire process and one QA person at the QA phase. (For a total of 5 months).  The rest of the task list is all new.

The question is this:  How do you respond?  If you have criticism of the process so far, please be very specific in how you would challenge or address the problem.  Remember, you’re just a coder, and you report to Joel.

Thursday, September 5, 2002

About the only response I can give to any type of initial estimate is:

- small (generally less than 2 weeks dev)
- medium (over two weeks but less than 2 months)
- large (over two months)

[also gives you some feeling of the type of projects I work on <g>]

If you want an estimate any more granular than "small, medium, large", you have to have it speced out and do your design work.

Thursday, September 5, 2002

Let's say you've given the "small, medium, large" estimate and they come back requesting harder time lines.  How do you reply?

Thursday, September 5, 2002

If they want hard estimates, then you have to write a spec.

The only way you can even get close is if you figure out all the nitty-gritty little details that need to be done, and assign an estimate to them and then add them up.

This will take TIME!  You can't just feed them a number.

Take the internationalization thing for example.  It is not just going to be char to TCHAR text replace.  It's going to be days of trying to figure out why when you write in Hebrew and save, and then click Publish, the last line of the published file appears as blocks. (or multiplication signs).  Then you'll have to spend 2 weeks going over every screen in the program with as many languages as possible to make sure that the strings you used don't overflow their dialogs.  Unless you write a spec, you won't even know what you have to do, and once you write the spec, you'll still have to figure out how the functional spec translates into the technical spec.

I'd estimate it would take you over a month, just to give them an estimate.

Michael H. Pryor
Thursday, September 5, 2002

Sounds like a MUD.  I would try to get a priority list on these things, hoping the Linux/MySQL thing falls to the bottom.  I would never actually intend to do the Linux port, just put it so far in the future that I'll have gone to a new company by then, or they'll have forgotten about it.  Maybe everyone will be running Linux by then, and it will have many nice tools.

I would probably suggest an ordering, unless I got the feeling they're the type to micromanage gratuitously.

Thursday, September 5, 2002

"This will take TIME! You can't just feed them a number."

Right!  So how can you explain that in a way that no one loses face or doesn't challenge the status quo?

If it does challenge that status quo, how can you minimize your risk? etc, etc ...

Thursday, September 5, 2002

Read Steve McConnell's "Rapid Development". This is an essential book for all software managers that are trying to communicate with both engineers and PHBs.

Zwarm Monkey
Thursday, September 5, 2002

> Right! So how can you explain that in a way that no one
> loses face or doesn't challenge the status quo?

There's no easy answer on this one. You should be the one best positioned to answer it, as you - hopefully - know the people you'd be dealing with.

I once took a project where the clients (in-house) were led to believe that their doc was "near perfect". It took me some time to convince them that we had to work some more on it. How did I do it? I was lucky. The project group was rather reasonable. And, AFAIK, this is the key concept - the whole group must be reasonable, otherwise the risk of failure (with or without proper specs) is extremely high.

> If it does challenge that status quo, how can you
> minimize your risk? etc, etc ...

You need time and specs to give them something worthy of the name "estimate". I don't know any way to minimize the risk. If the people you'd deal with were not reasonable enough to realize that correct estimates require a lot of input *and* a lot of work, then I doubt they'd be reasonable enough to get into a compromise about risk responsibility.

Suravye ninto manshima taishite ("Peace favors your sword")
Paulo Caetano

Paulo Caetano
Thursday, September 5, 2002

> Let's say you've given the "small, medium, large" estimate and they come back requesting harder time lines. How do you reply?

"Your guess might be as good or as bad as mine. Based on my initial 'small/medium/large' guestimate, are you still interested? I.e., do you now want to commit the initial resources that would be needed to develope a more detailed spec with a correspondingly more accurately-guessed timeline? I estimate that it will now take 'X' days to develope this next more detailed iteration of specs and timeline estimate."

Every unfinished project/schedule is "risky" in the sense that it still contains unknowns. Until we get into some details, we haven't yet even identified what this project's biggest risks might be.

Christopher Wells
Thursday, September 5, 2002

Best job advice I ever got:  "You can't reason with a madman."

The worst is when the time that could be spent putting together real specs is wasted on meetings about how "we should be putting together specs."

Contrary Mary
Thursday, September 5, 2002

Something I read on this site a while ago...
Ask them how log it takes them to drive home, if they say
30-40 mins. 10 - 20 mins etc, ask them why they have a 30%, 50% variation on a task they have done hundreds, maybe thousands of times.

Tell them you estimate is accurate to about 30-50% as well.

Thursday, September 5, 2002

"Tell them you estimate is accurate to about 30-50% as well"

If you can do 30-50% accuracy consistently right of the bat on this level of detail you're not a planning superstar, but a planning god!

Just me (Sir to you)
Friday, September 6, 2002

Answer the question with questions. Ask when do you need each project? Which has to be done and which are wishes? How many new hires? How many QA people? Has marketing finished the feature list? Have contracts been signed for any of this? What is the budget? What about training and training budgets? Do we have tools in house? Are we buying new tools? Now computers?
The questions show you are interested and concerned. You are trying to make sure everything is covered. You look good, you get some answers (you never get everything), your estimates get better, and you keep the ball in their end of the court.
While you are waiting for answers, work on the specs, try out the tools and refine the estimates. Soon you will have confidence in your schedule estimates.
Never, ever give in when the big boss asks for a back of the envelope, just to give us an idea, time estimate. This will bite you on the ass every single time. If you guess too long, everything gets canceled. Guess to short and that is the only number anyone will remember. Do not give any numbers without documentation, gant charts, and a good task list. Say, "I could give you a number but only when Bob answers my (last thing I asked) question." Deliver the estimates when you are ready!

Doug Withau
Friday, September 6, 2002

I've used the following technique with "mixed" success.  If the request is for immediate estimates, I indicate that it will take "X" widgets long, where I reserve the right to define what a widget is.  That usually helps bring out some urgency in defining more solid requirements than "integrate x with y"

Friday, September 6, 2002

Don't be so afraid to be wrong, back your judgement and go for it!

Friday, September 6, 2002

> Right! So how can you explain that in a way that no one
> loses face or doesn't challenge the status quo?

How much is your team's morale worth to you?

The hardest thing for a parent company to do is absorb a new culture.  Educate them patiently.  Because once you lie or work around ignorance, you've lost your own culture.

Friday, September 6, 2002

If you are "just a coder", you shouldn't be making these decisions.  I agree with prev. posters, you can't give an estimate until you examine the score/requirements in more detail.  And don't be afraid to say that.  You want an estimate?  Then lets look at when needs to be done!  Don't go beyond small/med/hard until then.,

Saturday, September 7, 2002

If the "executive" doesn't know enough to make these judgements himself, he's not competent to be an executive. Also, this is an indicator of looming disaster.

Sunday, September 8, 2002

*  Recent Topics

*  Fog Creek Home