> While true, it's also true that most times (IME at least) the boss doesn't 
> want to wait that long. In particular, the boss doesn't want to spend the 
> time it takes to describe out all the details to the point where you could 
> give an accurate estimate before he has an estimate he can rely on.

Well of course if you think your project is only going to take 1-2 months to 
complete you are not going to spend 3 weeks planning it :-)  I don't know 
what a good ratio is, but I would imagine someone has researched this and 
written about it somewhere.  It will also depend on how similar your 
projects are to previous ones, obviously if they are pretty similar you 
won't have to spend much time to get a very accurate estimate.

> If you look at (for example) function point analysis, it requires that you 
> know every field of every table in the database, every column of every 
> report, every input to every entry form, what the equation is to calculate 
> any derived information, and a few other things like that. By the time 
> you've figured out an entire business system to this degree of precision, 
> you might as well just code the damn thing.

Well yes, that seems a little over the top for simply getting an estimate of 
the time needed to design and implement the thing.  It's like me saying that 
I should document every single detail needed on every mechanical part and 
how long it will take me to design it, of course it's quicker then to just 
actually do the work!

> Which is not to say my bosses aren't foolish, but clearly "design it all 
> and we'll tell you" doesn't work in most situations. Especially when the 
> requirements change faster than you can code them.

In our business the requirements change way quicker than we can implement 
them, it's always a case of going back to the customer and saying "ok this 
change will delay the schedule by X weeks and cost you Y".  Then there is 
usually some negotiation and we come to an agreement of what to do.

Post a reply to this message

> "Programming is not like building a house over and over again. If you 
> build
> your first house, you have no idea how long it will take to build a wall,
> make the roof or creating one square meter of floor.

I would say the analogy is being told to write a game in C++ and DirectX. 
Your first time, when you have no experience of either C++ or DirectX, is 
going to be a nightmare.  You will have no idea how long it will take, what 
is possible, what isn't possible, there will be lots of problems etc.

> Once you did all this,
> you know how long it took and when you build your second house, you know
> that it will take about as long as it did the first time, if not faster,
> since you are getting better at a task the more often you are doing it.

Yup, once you know how to code in C++ and use DirectX it becomes vastly 
quicker and more predictable to write a game, even if it's not an identical 
copy of your first attempt.

> Every piece of code you write is a *new* piece of code, you are never
> repeating the same task again. Why would you repeat the same task?

Because it needs to be slightly different?  Like an app that needs a GUI 
front end, not going to be the same as anything you've done before, but you 
know how to make one because you've done it before 100 times.  Ditto for a 
physics engine in a game, you know how to do it, but you might need to start 
again from scratch or modify your existing code because of some special 
requirement (eg it was a flight sim before but now you need car sim 
physics).  Or you need to read/write to a database, yes you know how to use 
mySQL already because you've done it before loads, but you still need to 
write some code again that you are familar with, it's not really new to you.

Post a reply to this message

scott wrote:
> Well of course if you think your project is only going to take 1-2 
> months to complete you are not going to spend 3 weeks planning it :-)

It's not that. It's the boss asking "will this take 3 months or 4 months" 
and you say "It'll take me 3 hours to figure that out" and the answer is 
"that's too long..."  IME, he's usually on the phone with the customer when 
he asks, assuming he even asks before making a promise. :-)

> Well yes, that seems a little over the top for simply getting an 
> estimate of the time needed to design and implement the thing.

Not when you're charging the client what you hope is $250/hour, and you 
don't want to be off by a couple dozen hours in your estimate, thereby 
losing several thousand dollars on the job.

It's hard to get an *accurate* estimate before you know what you want. It's 
the whole "how much does the house cost to build?"   "Show me the 
blueprints."  "We don't want to buy blueprints before we know if we can 
afford the house."

> In our business the requirements change way quicker than we can 
> implement them, it's always a case of going back to the customer and 
> saying "ok this change will delay the schedule by X weeks and cost you 
> Y".  Then there is usually some negotiation and we come to an agreement 
> of what to do.

And during the negotiation, are you re-doing the estimates? While sitting in 
the meeting with the client?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message