Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
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
> 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
> It is bad architecture, or usually the lack of even considering the
> 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
> to the 80% level or so, adding new features breaks old ones to a point
> 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
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