Bob La Quey wrote:
No most such projects have versions. I do not see that it
has to be set in concrete. But one can have months between
versions rather than say days.
You work on different kinds of projects than I do. Weeks is a luxury.
Maybe that is the main difference. I am not talking about
a system of development where there is no feedback between
the spec writers and the coders. That would be absurd. I am
simply saying that on a large project you better have a damn
good idea of what you want to do (i.e. a spec of some sort)
before you start the doing. Do you really argue otherwise.
I agree, on a large project. The bigger the project, the more time you
have to do specs and such. But there's an awful lot of churn, when
you're working on something for which it's impossible to have specs
before you start coding.
Sure, if it's well-understood before you start coding, things are a lot
easier.
Ok. I apologize. I must have inferred from your comments
that you considered the spec so difficult that it consumed
90% of the effort. I see it as more like 25% of the effort.
A spec you can "throw over the wall" is often 90% of the effort in the
kinds of systems I work on, which tend to consist of putting a lot of
poorly-documented parts together, or responding to the concerns of
customers of my customer.
By the time you do enough RAD to know if and how it'll work, you might
as well just finish it.
Pure top down tends to develop exactly the problems
that you are describing.
No, that sort of thing happens when 50% of the functionality of your
code comes from someone else.
Software development is difficult because of the
issues you mention many of which can be characterized
as ambiguity. Indeed one might say that software
development is simply the reduction of ambiguity
to zero.
That's good, yes.
I suggest that one advantage of having say separate
groups work on a project is that the interfaces
between the groups and their work products need
to be written and rather formal, not the sort
"Hey Joe, what is in that struct" sort of informality
that often goes on in a single tight knit group.
Agreed, if what you're working on is fully under your control, and you
have time and money to "do it right".
When 50% of the interfaces in your code are to 3rd party software that
isn't documented, coming up with those formal specs *is* writing the code.
sometimes it is a good solution.
Yah.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
