Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] "Just Good Enough" (was: Handling team members who inflate their workload)

Expand Messages
  • Ron Jeffries
    ... Yes ... high quality code, doing exactly what the Product Owner and team have agreed to ... no less, AND NO MORE. ... Big wrong, times two. First, the
    Message 1 of 2 , Apr 24, 2006
      On Monday, April 24, 2006, at 3:21:28 PM, David A Barrett wrote:

      > Well, I guess I expected some resistance on this point.

      > 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.

      Yes ... high quality code, doing exactly what the Product Owner and
      team have agreed to ... no less, AND NO MORE.

      > Here's a real life example that happened co-incidentally with this thread:

      > 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?

      Big wrong, times two. First, the programmer wasted a bunch of
      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. The
      > 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.

      Yes ...

      > So at the end of the day, the organization was robbed of this programmer's
      > 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.

      Exactly true. Programmer wasted Product Owner's time and money. Bad
      programmer! No biscuit!

      > There are probably times when there's a fine line between "Just Enough" and
      > "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.

      Over-engineering is invariably, always, inevitably bad engineering.

      Ron Jeffries
      www.XProgramming.com
      I'm not bad, I'm just drawn that way. -- Jessica Rabbit
    Your message has been successfully submitted and would be delivered to recipients shortly.