I lean in Lars's direction a bit, although not quite as much as
Pind's Rule of Five. My biggest concerns is that there's huge risk
of a second system effect on survey. Everyone has seen the
current module, and everyone has grand ideas for how it should
work next. There are probably a number of goals between all of
us:
- branching: a huge amount of work for such a small word.
- a generic survey engine: to provide a base for other packages
that are based on a survey-like process (quizzes, etc...).
- more answer types.
- better results processing / correlation.
- ability to link surveys to other objects in the system, make
certain actions dependent upon the completion of a survey.
(and I'm sure there's plenty more)....
There's a good reason to be conservative here. One solid path
might consist of focusing on a clean architecture to start and *
only then* adding features in an iterative manner. Given the
current state of the survey package (horrendous), just rebuilding
a clean architecture will be plenty of work in and of itself.
