"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

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

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

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