Gerhard Fiedler email (remove spam text)
> Olin Lathrop wrote:
>> You keep saying this, but I don't think the waterfall method is
>> taught like that.
> I know real projects don't work this way. But I know they still teach
> it in technical colleges.
That's a problem with those colleges that has little to do with what
we're discussing here. Apparently most of the students forget about this
-- just as they forget most of the other stuff -- the moment the
semester is over :)
>> Not if you want to be able to use the early work without
>> architectural changes or scrapping it completely.
> Nothing wrong with architectural changes. :) This is software we're
> talking about, right?
Now come on... this is software we're talking about, and changing the
architecture in mid-course could easily cost you half a million extra.
If that change was avoidable and it was my money, I probably would be
pissed. The impact depends on the size of the project and other factors,
and can be a real disaster -- and can mean the death of the project (and
possibly the company, if it's a startup, the project is its only one,
and investor funding is running out).
It's not that because it's software, architectural changes are always
easy. You don't need to re-layout a board, but you may have to do a few
things that are just as much work.
>> Also nobody said you need 100% of the requirements up front.
> I'm sure Gerhard said something along the lines that on some projects
> you need to do most of the design work upfront.
I don't remember, but it sounds as if I could have said this. What's
your point though? "Most of the design work" is not the same as "100% of
the requirements". There are two important differences: one is "most" vs
"100%" (which means "all"); I hope this is obvious enough. The other is
"requirements" vs "design work". You don't need /all/ requirements up
front, but you need the /important/ requirements up front if you don't
want to waste time. I suggest you better make a reasonable effort to get
the important requirements as early as possible, best before starting
with the first iteration, even if they are not what you plan on working
on during your first iterations. This allows you to do "most of the
(architecture) design" up front, and makes sure that you have a useful
direction for your iterations.
IIRC, one of the Agile mantras is that the best code is the one that you
don't have to write (or along these lines). This is an important one,
and it can also be extended onto refactoring: the best refactoring is
the one you don't have to do. While I'm all for seriously considering
refactoring when it's warranted (instead of kludging stuff on top), I'm
even more for avoiding later refactoring (and coding) where possible by
thinking ahead. Even if this means thinking a few iterations ahead.
In reply to: <6184B0998CF24488BBD5C383061B8B8E@ws11>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the