Re: [scrumdevelopment] "Just Good Enough" (was: Handling team members who inflate their workload)
- On Monday, April 24, 2006, at 3:21:28 PM, David A Barrett wrote:
> Well, I guess I expected some resistance on this point.Yes ... high quality code, doing exactly what the Product Owner and
> I can only emphasize that "just good enough" doesn't refer to the quality
> of the coding, but to the quantity of features supported and the exclusion
> of "stealth" non-functional specifications.
team have agreed to ... no less, AND NO MORE.
> Here's a real life example that happened co-incidentally with this thread:Big wrong, times two. First, the programmer wasted a bunch of
> Good XML example snipped ...
>>From this I determined two things:
> 1. We had never used the multi-valued capability, and it was wasted
> programming effort for over 1 year.
> 2. No one had tested the multi-valued capability. Why would we? How
> would we have justified it?
someone else's money writing code. Second, the programmer wrote code
that DIDN'T EVEN WORK!! Arrgh.
> To me, this is classic "Just Good Enough is NOT Good Enough" thinking. TheYes ...
> programmer obviously thought, "I'll save the organization time and money in
> the long run by sneaking this functionality in here now, while I'm already
> in the program." For all he knew, at the time, we might never have needed
> this functionality. Truth be told, if it wasn't already there, I probably
> wouldn't have added it when I needed it, but worked out a way to send the
> data without using multi-valued fields. No one would have cared.
> So at the end of the day, the organization was robbed of this programmer'sExactly true. Programmer wasted Product Owner's time and money. Bad
> time while he was sneaking this functionality into the program.
> Furthermore, we were saddled with untested code and features that we didn't
> know existed that added to the complexity of an already too complex system.
programmer! No biscuit!
> There are probably times when there's a fine line between "Just Enough" andOver-engineering is invariably, always, inevitably bad engineering.
> "Too Much". There's probably a thousand more times when the line is
> perfectly clear but an overly zealous programmer can resist
> over-engineering something he knows would work just good enough if he stuck
> to the official specs.
I'm not bad, I'm just drawn that way. -- Jessica Rabbit