Jeff Jonas wrote an interesting post – Custom Software Scope Changes (Not) – that reminded me of my ongoing battle to argue that rules are not requirements. Jeff argues that we take far too little time designing custom software before we start to build it. A summary quote from his post illustrates his point:
I am talking about robust architectural plans: complete screen layouts with error messages, full report mock-ups containing realistic data and sub-totals. I am talking about a degree of design completeness that the specifications could be used to simulate (e.g., in paper form) the use of the whole system by each type of user.
Now I think he has a good point here but if, and only if:
- The software design is not considered done unless the actual users have spent a considerable amount of time actually working with the simulation to see if it works for them
- The design on paper describes the decisions to be made but does not attempt to “fix” the rules that drive those decisions.
The first is important because it is not reasonable to expect the design to be “right” unless the users have experience with the simulation. The analogy to buildings falls down because we are used to buildings and good at simulating them in our minds eye, much less so software. The second is important because the rules change all the time and so cannot be pinned, like dead butterflies, to a piece of paper. Two of the comments Jeff received reiterate my point in slightly different language:
…build a working web application, minus the more complex logic, more quickly than I could in the paper form
Note the qualification that the “complex logic” is excepted from this. If this logic, the logic behind business decisions, were managed as declarative rules that could be changed and evolved once the system was up and running then this would allow the more rapid development of the application. The other commenter makes a different point:
specs are often written by technology types, and the business doesn’t understand them (or in many cases, doesn’t read them)
True and another reason for business rules so that business users can actually manage and control the logic behind their decisions.
Personally I think good software can be built from specifications and/or prototypes in many combinations with different ratios for different circumstances but it is essential to keep the business logic, the rules behind the business decisions, separate and managed.
