Scope Control

TomPlunket wrote:

I'm more interested in fewer features with no bugs

The ExtremeProgramming party line is not fewer features, it is less scope in each feature. Given the requirement 'the user types in 30 numbers', do you let them write a text file and feed it in? Or do you put a spreadsheet on a window and let them type? Or all of the above?

Recall that modern GraphicalUserInterface toolkits come with lite spreadsheets, so both options are equal cost. But what if the OnsiteCustomer neglected an aspect of those numbers, such as they typically come in via e-mail?

The OSC(= OnsiteCustomer), reviewing the feature as it develops, might remember this detail - typically via role-playing. They'l be inspired to request a large edit field. It will take 30 numbers, separated by linefeeds. Pasted in.

The feature is finished, but the scope within that feature got reduced down to a single edit field. We did not need to put in every import system we could think of. We put in the one that worked best, right away, for the OSC. Then we stopped. That's ScopeControl.

(the first public showings of our game had no crashes! Woo hoo!), and we're doing a timebox-style of development these days. Basically the tasks are arranged such that lower-priority tasks get dropped if necessary rather than allowing bugs to remain in the higher- priority code while more bugs get added with the lower-priority stuff.

The bad way to do that is to over-require each feature, then "don't interrupt the programmers" until the feature's done. Sorting priorities (PlanningGame) must happen in real-time, on a line-item basis. No batch mode.

Of course, if the test harness is decent (as it was around my body of code), then your bug list is short to begin with so it's trivial to go in and fix up the low-priority bugs (which in my experience tended to be feature/change requests rather than bugs).

D'oh! Don't run bug-free! Your plan will backfire!! They'l give you the hardest work, never review it, and never learn how you are doing it!!!

• What an unfortunate truism - PeterLynch

--PhlIp