 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> The real problem with putting software on a schedule is that during
> development a program is being written for the first time, and for that
> reason nobody really *knows* how long it will take. Sure, the boss can
> guess how long it will take, based on experience with similar projects,
> but at the very best he/she is making an educated guess.
Indeed.
Mind you, arguably the same principle applies any time anybody designs a
new product. How long does it take to design and build a house? Well,
you can take an educated guess, but...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Mind you, arguably the same principle applies any time anybody designs a
> new product. How long does it take to design and build a house? Well, you
> can take an educated guess, but...
Usually you can break the task down into smaller ones and then each of them
down again, until some sensible limit. You (as a team or company or group
of companies) should then be able to quite accurately estimate how long each
of those tasks is going to take, assuming you have done anything similar
before. You then get all those nice "critical path" diagrams using MS
Project that show you where the bottlenecks are and what's taking up all the
time.
For example, suppose you know that you need a GUI developed for your latest
piece of software, presumably you employ someone with experience of this,
and they can break it down into different parts, some of which might rely on
other parts of the software being completed first, and then at least have a
reasonable idea of how long each part is going to take. Sure they might hit
problems along the way, everyone does not just in software, but this happens
less often to a skilled and experienced team.
I remember reading somewhere that people are pretty accurate at estimating
how long it will take them to do things, it's just they consistently over-
or underestimate the time. So as long as you (as a project manager) have
some record of the peron's previous work, you should be able to get a good
idea how long it will take just by asking them and factoring out their
internal time scale multiplier :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Usually you can break the task down into smaller ones and then each of
> them down again, until some sensible limit. You (as a team or company
> or group of companies) should then be able to quite accurately estimate
> how long each of those tasks is going to take, assuming you have done
> anything similar before. You then get all those nice "critical path"
> diagrams using MS Project that show you where the bottlenecks are and
> what's taking up all the time.
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.
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.
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.
> I remember reading somewhere that people are pretty accurate at
> estimating how long it will take them to do things, it's just they
> consistently over- or underestimate the time. So as long as you (as a
> project manager) have some record of the peron's previous work, you
> should be able to get a good idea how long it will take just by asking
> them and factoring out their internal time scale multiplier :-)
From experience, this is true. But you have to track things pretty well.
Joel Spolsky has (http://www.joelonsoftware.com/) has software that tracks
it and then does a statistical analysis to give you confidence intervals.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Mind you, arguably the same principle applies any time anybody designs a
> new product. How long does it take to design and build a house? Well,
> you can take an educated guess, but...
A house is not a new product.
"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. 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.
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? If you
ever need the same code again, you copy&paste it; that will take you about
5 seconds. If you ever need the same application again, you just copy the
one you wrote last time.
A software developer faces the problem that he needs to write new code
every day, as there is no point in writing *old* code again. So every time
the task is a new task for you. It's like you are building a house today, a
car tomorrow, and creating a lovely garden the day after tomorrow; and you
are always doing it for the first time. How can you estimate in advance how
long you will need for it?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Invisible wrote:
>> Mind you, arguably the same principle applies any time anybody designs a
>> new product. How long does it take to design and build a house? Well,
>> you can take an educated guess, but...
>
> A house is not a new product.
I'd debate that.
Is every house *exactly* the same? Probably not.
Is every item of software *completely* different? Probably not.
If you're a company that specialises in writing stock control systems,
you probably know a thing or two about how to make a stock control
system work. But, of course, every client is different, so you can't be
completely sure how hard or easy it will be this time...
> Every piece of code you write is a *new* piece of code, you are never
> repeating the same task again.
Sure. I won't argue with that.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> If you're a company that specialises in writing stock control systems,
> you probably know a thing or two about how to make a stock control
> system work. But, of course, every client is different, so you can't be
> completely sure how hard or easy it will be this time...
And to the extent it's identical to what you did last time (or
parameterizable), you can reuse the old code. All the work you do on the
second stock system is new.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>
> Is every house *exactly* the same? Probably not.
>
Umm, actually ... a builder can build multiple copies of the same
floorplan, with only minor changes. So, the builder may have 5 different
models in an neighborhood of 1500 houses ...So, it pretty much is the
same for the majority of houses.
Once you've framed a wall, you pretty much know what it will take to
frame the next wall. The framers do not have to sit out there and draw
in the sand to figure out *how* to frame a wall. They just do it. Not
only that, but in many cases the wall components are dropped off at the
site with markings designating where that piece goes, and where all of
the other pieces attach. Not at all like a software program, where
you're figuring out how to do something.
Even better when the builder is using a prefab method, where wall
panels, trusses, and other components are built in a factory, then sent
to the site.
And in the factory? The pieces get cut by big automated saws, dumped
into a bin, and carted to an assembly jig where a laser projects the
outline of the pieces, the pieces have markings on them to designate
where to go, and (at least in the case of complex trusses) a set of
automated pucks have lined themselves up on the outside, so all they do
is pop the chords down, then drop in the webbing according to the
diagram they see on their screen or projected on the table-top.
>
> If you're a company that specialises in writing stock control systems,
> you probably know a thing or two about how to make a stock control
> system work. But, of course, every client is different, so you can't be
> completely sure how hard or easy it will be this time...
>
Yes, but if you're wanting to develop a new stock control, you'll need
to figure out how to draw and create interaction for that particular
control.
>> Every piece of code you write is a *new* piece of code, you are never
>> repeating the same task again.
>
> Sure. I won't argue with that.
>
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
