[clue-talk] L

[Nate Duehr]

On Dec 17, 2006, at 12:46 PM, Jed S. Baer wrote:

> But it's a 2-edged sword. There is (or used to be?) a time-honored  
> rule of
> thumb: prototypes aren't. The scenario being that when the users  
> get the
> prototype, they then want to immediately start having that  
> functionality
> available, and the prototype winds up being the delivered system. I  
> don't
> know how often this happens, and I've encountered it only once, on a
> system that had already been in production for a while when I  
> joined the
> team. (Which is how I wound up writing Basic+2 -- and later  
> Macro-11 -- on
> a PDP-11.)

The "prototype isn't" happens a lot more than most (isolated from the  
customer) developers believe.

Somewhere in an office, their manager (under pressure to deliver  
something) works out a "deal" with support management to push the  
prototype out to the field with the understanding that the support  
group will fully support it until Engineering catches up.

Been there, done that, FAR too many times.  All of this theory about  
how to produce better code generally means little to those of us who  
support the "previous" versions of things, and get sucked into  
management's whacky ideas about what should go out the door, and what  
shouldn't.

And at the end of the day, whatever the customer has in their hands  
TODAY either works right and they're happy with it, or it's just  
another notch on their belt of painful memories to affect the  
customer relationship for years to come.

Until customers start penalizing software houses for bugs,  
monetarily, all the above will continue to be a debate.  And the only  
way that will happen is if customers and vendors work together to  
create good requirements... so I agree that requirement gathering is  
a great thing -- but these methodologies that produce half-backed  
products quickly and then roll them on a never-ending cycle, simply  
don't fit the model of business where a contract and a product are  
"delivered" for payment.

The only model these methodologies fit is a relatively new one... a  
permanent service contract.  You have a service contract, you get  
updates/upgrades.   You drop the contract, you no longer get to talk  
to anyone about what you want changed.

--
Nate Duehr
nate at natetech.com