Olin Lathrop wrote:
>> You seem to assume that "careful architecture approach" guarantees that
>> you don't end up with a ball of bandaids.
>
> Careful architecture doesn't guarantee anything, but it does decrease the
> chance of ending up with a ball of bandaids.

This sounds reasonable to me.


>> The fallacy of this argument
>> is that you claim to predict the future. By definition, a project has
>> many unknowns. Design upfront means design based on assumptions (aka
>> bad information).
>
> So you have two choices.  Architect with some idea of the future or none 
> at
> all.  In many case the "some idea" will be good enough to be useful.

It's not black-and-white. While jumping right into coding without any 
planning is a terrible idea, it's also possible to architect a project to 
death. It's the proverbial "paralysis by analysis".

I'm not advocating against planning per se, only excessive, overly detailed 
planning that looks too far into the future, and is therefore largely based 
on assumptions. That's why I like the iterative approach, where planning is 
followed by writing actual code. You gain useful information after every 
iteration.


> It is bad architecture, or usually the lack of even considering the 
> overall
> architecture that got them into this mess in the first place.  Anyone can
> make the first 20% of features work.  With a bad architecture, once you 
> get
> to the 80% level or so, adding new features breaks old ones to a point 
> where
> the project stalls and the consultant is called to "finish" the last 20%.

I've been there. A few months ago I described my experience with refactoring 
(you remember, I made the famous statement about keeping functions under 10 
lines), but sometimes the mess is so bad you just have to start from 
scratch.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist