Fortunately there is a direct and effective process for converging on the
selection of a concept when developing a new product. Perhaps it can help the
team settle the IRML / P issue.
I learned it as "Pugh concept selection" but it is called "Controlled
Convergence" in this reference:
http://www.betterproductdesign.net/tools/concept/convergence.htm
(A more complete description is in Stewart Pugh's book:
http://www.amazon.com/exec/obidos/tg/detail/-/0201416395/qid=1063324278/sr=1-1/ref=sr_1_1/104-1770677-0827969?v=glance&s=books
Those who have read both the IRML spec and the P spec have completed step 1 of
the process.
I believe step 2 is a difficult one. Basically the team has to agree on a list
of requirements or specifications for the solution. This actually seems to be
where the debate has centered. Here is a starting point:
1) Easy to write (by programmers or non programmers? Using a simple editor, a
structured editor, or a GUI? seems like this has to be decided)
2) Easy to read (by whom, similar set of issues)
3) Easy to edit and update (by whom, similar set of issues, do we need hot
slide in?)
4) Easy and clear expression of rules logic including . . . (fill in the blank
- I think if / then / else does a lot. what more is needed? Perhaps Alex's
reference set of rules can help here)
5) easy to write parser / interpreter (this begs the question of the run time
representation - text, byte code, object code, or else?)
6) easy / fast to run (how fast is needed?)
7) Compact storage on the processor
8) etc.
9) etc.
10) etc.
I propose the working group continue to debate the list of requirements,
(perhaps using the above list as a starting point.) When the list of
requirements converges, I would be happy to lead the team through the remaining
steps of the convergence process.
Is this sensible and helpful?
Lee Beaumont