Tuesday, July 26, 2005

Qualifying the "Simplest Thing" rule

In XP, and Agile methods, decisions are often made with the criteria of "the simplest thing that could possibly work." I think this applies not only to code construction and detailed design decisions, but to Architecture as well. Strict use of this rule will almost always result in the most prudent approach, but I do think there are a couple of caveats:
  1. The decision should still be reversible, so that you don't paint yourself into a corner for future changes in the requirements.
  2. The simplicity should be weighed carefully against the flexibility and the cost of changing later. If the simplest solution costs 20% less now, but will likely cost 30% more over time, then it may not be the best choice. You have to decide how likely likely is.

I would stress that even with these caveats, one should still be very careful breaking the rule. If you don't have a strong case for a very real risk of ir-reversibility problems or future costs, you should just stick with the simplest solution.

No comments: