Berin wrote:
|  Even when Quick and Dirty takes longer.  I tried to convince my boss 
|  a certain "customization" required so many fundamental changes that it 
|  be quicker and easier to develop/maintain if we did it right.  He told 
|  that he would never be able to convince the CEO that was the right 
|  so the "Quick and Dirty" route was the choice--taking me twice as long 
|  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 

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.


To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to