This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: "One Best Way" versus "Options"
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
A book I have talks about preferences for 'one best way' (also called 'process') versus 'options'. 'Process' people want one way to do things, want to be told how to do it that way, and want to be told that it is the 'best' or 'right' way.
'Options' people always want to invent a better way. If they're told 'x process' is the 'best way', they'll try to find a better. Options people are good at inventing processes, but not so good at following them.
When talking to 'process' people, if you can establish your credentials as someone who should know the 'best' way, explain how following the process of test-code-refactor insures good design. Explain the rules of good design (modularity, encapsulating behavior, cohesiveness, low levels of coupling, etc.) and give examples of how following the test-code-refactor process produces code that meets those criteria and how design-code-(maybe-test) so often fails to produce code that meets those criteria.
If you are talking to options people, you can mention how a whiteboard design session before TDD can let you explore options in the design, and how the rules of good design creates flexible code - allowing more options on how to use the code in the future.
To get 'process' people to consider options, repeat this phrase:
"One choice is not a choice, it is a trap;
two choices is not a choice, it is a dilemma;
three choices is a choice." (I believe I got that saying, perhaps worded slightly differently, from Jerry Weinberg.)
Repeat this saying often. Establish it as a process to follow to avoid traps and dilemmas.
Previous Topic
