> Nat wrote:
> > The radical concept is that once those steps are out of the way, and a
> > competent, experienced architect has written Fusestubs (Fusedocs in an
> > otherwise empty file) for all the fuses, it will only take a day or so
to
> > have the actual coding done, by using a distributed development
approach.
>
> What I've never understood is how anyone can possibly write perfect
> fusedocs for a large scale application. Isn't that tantamount to
> writing more than a nominal amount of code and having it work the
> first time -- only on a much larger and more difficult scale?
I agree with Patrick and he hits the nub of the point right on. Or at least
one of the points with respect to a raised eyebrow towards the 48-hour
project goal.
Nat points out, and I think correctly too, that after all this other work is
done, *then* doing the code is something that can be done in the 48-hour
time period. But it really, REALLY begs the question: if you've got so much
of the project done up to that point that the coding becomes almost a
trivial afterthought, then the "impact" of the 48-hour turn-around time is
simply marketing...it sounds great, but the implicit assumption is that all
the "real" work is done. Well, if all the work is done, then the last 48
hours are no different than slapping some paint on the walls when building a
house--who cares if it is 24 or 48 or 72 hours?. And if the work is not all
done, then the paint is useless until it is.
Don't get me wrong, it is certainly a better approach than the 48-week
project :) But that same pyramid where key points of work remain on the
shoulders of the architect have to be addressed, esp in terms of multiple
revisions to the Fusedocs, as Patrick points out.
(I will say to Patrick, though, that if there are problems with teh Fusedocs
then the problems tend to effect only that fusedoc and the several templates
that may derive input from it or provide input to it -- so the types of
fires the architect is putting out in de-bugging his fusedocs may be many
but are much smaller)
I have these nightmares of clients getting sold on the 48 hour idea, and
then suddenly it's either the architect who's getting slammed at the last
minute due to too-aggressive selling on the sales department's part, or the
client gets pissed off 2 months into the project when the architect is still
doing his stuff and it's being fopped off as 'well we only meant 48 hours
once the archiect is done". Again, it comes down to assuming that the sorts
of things that impress developers are the same things that impress clients,
and they are just vastly different, and it promotes talking to other
technology people at the client's location rather than talking to the
decision-maker himself. By and large technology people at the client's
locale are not the ones signing off on the money; the way to capture big
money accounts and to keep them is in your relationship with management from
the top-down , not from the bottom-up. And management from the top-down
generally dont give a doodle as to whether you can get it done in 48 hours.
(in fact, if you tell them it will take you several months, you'll be able
to still get it done in 48 hours, and still charge them for several months
of work but deliver a month early.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
