email (remove spam text)(Olin Lathrop)
> Brooks says "build the first [system] to throw away; you will, anyway".
> point is that you build the first one to learn from, and then you build
> second one based on that experience.
> I don't subscribe to that point of view, but I agree that in general you
> can't design a perfect system on the first try.
> So what we do, is accept that change is inevitable, and make an effort to
> isolate and contain it by employing appropriate design practices. We don't
> build one system, throw it away, and write a second one from scratch. What
> we do is learn throughout the project, with every iteration building on
> of the ones preceding it. Refactoring is key, it's the one technique that
> allows the project to gradually be chiseled into its final form.
The obvious approach to me is to gather the requirements you can up front,
take a stab at a reasonable architecture based on what you know, then start
implementing. The requirements will always change at least a little. With
good architecture and with some experience with what is likely to change,
the little changes don't usually require large structural changes. If
something does require large structural changes you're no worse off than in
your system. Often enough though you do get enough right up front for that
to be useful and therefore save effort in the long run.
> Your example is understandably contrived, but here is how I would approach
> this project:
> First, I would create a quick sketch on a napkin or better yet, a
> whiteboard. I would draw a quick block diagram, and a simple drawing of
> product's appearance. "Is this what you want? Do you want 12 hr or 24 hr?
> How many users would this NTP server serve? Etc."
But you're not allowed to do that as it's not required for the first
iteration. You seem to understand intuitively that this up front planning
is required, but note how this is a lot more than planning for just the next
iteration. You have to have some idea where you're ultimately going before
you put your head down and dig in to get that first chunk done.
I mostly agree with this, but this is not the process as you have previously
described it. This is looking ahead a lot more than a single iteration.
> What I would *not* do, is try to commit every single detail down to paper,
> before doing any actual work.
If this were a fixed price project, then lots of details had better be
written down, both for your protection and mine. These details are the
what, not the how.
>> Code yes, but you do have to architect the system for the full feature
> Not in my experience. It is possible to start with a simple system with
> a subset of the final feature set, and build/refactor it into the final
I guess this is the fundamental disagreement that will remain a
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.
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