Berin wrote: | Even when Quick and Dirty takes longer. I tried to convince my boss that | a certain "customization" required so many fundamental changes that it would | be quicker and easier to develop/maintain if we did it right. He told me | that he would never be able to convince the CEO that was the right choice, | so the "Quick and Dirty" route was the choice--taking me twice as long to | get it done.
Preferred pain is a known pain with an experience-based cap. New and improved pain may promise an average POI (Pain-on-Investment) that is 50% of the familiar pain, but will be assigned a risk profile with unknown maximum pain. If your previous experience confirms that max(NewPain) <= max(OldPain), then go ahead and implement NewPain, but make it look like OldPain. If max(NewPain) turns out to be >> max(OldPain), you're on the hook. But you would have first hand experience to make the call, whereas your boss (and definitely his boss) would not (or they wouldn't object in the first place). One successful implementation of NewPain where max(NewPain) <= max(OldPain), while delivering promised improvements, will set a precedent. But someone has to take the risk. And it won't be people twice-removed from the pain. ... in my (painful) experience. Rich -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
