![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Attempting to put software to a schedule is analogous to solving Turing's
halting problem for a given input."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez wrote:
> "Attempting to put software to a schedule is analogous to solving Turing's
> halting problem for a given input."
...except that the Halting Problem requires you to be able to analyse
arbitrarily complex programs, whereas useful software is not usually
arbitrarily complex. <insert remark about government projects here>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Nicolas Alvarez wrote:
>> "Attempting to put software to a schedule is analogous to solving
>> Turing's
>> halting problem for a given input."
>
> ...except that the Halting Problem requires you to be able to analyse
> arbitrarily complex programs, whereas useful software is not usually
> arbitrarily complex. <insert remark about government projects here>
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.
Regards,
John
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |