demexpA long long time ago, I worked on demexp, a specific software made to support the Democratic Experience, a direct democracy initiative. demexp is programmed in OCaml language. The software contains both a server and a client. The client user interface is programmed with Gtk+. I also tried to make a web interface, without much success. The whole software is made in literate programming style. After several years of development, I was bored and stopped working on it. The software project never had a lot of momentum. The Democratic Experience political project is still alive, without much activity as far as I know.

After those years, one (at least me ;-) ) could wonder what failed in the project and how it could be improved, from a software engineering point of view. I see three main points to work on if one wanted to re-engineer demexp.

1. Start from a well-defined high-level specification. When we started demexp, we did not know exactly what kind of software we wanted. We discovered a new territory. Nowadays, I think we could have a much clearer picture of the requirements. As for any software, starting from clear requirements is mandatory. :-) So we should start from a set of high-level requirements, from which derive some low-level requirements for the software.

2. Design a modular architecture. I made demexp as a big monolithic software. The server part contained the network interface, the question and response database, the security model, the delegation system, etc. The client was containing a User Interface as well as code to authenticate the user and access the server. I now think I should have started from a much modular architecture, with several small programs, each one of them focused on a part of the system. Having several programs would force me to have clear interfaces between them, thus imposing a cleaner architecture. And if the task of developing all those programs is too big, at least I could focus on a sub-part of them to have a system with less functionalities, but at least working.

3. Use formal methods to verify some properties. Using formal method is not strictly required, but, well, it interests me :-) and I think formal methods could bring benefits to such a software. For example to prove that some properties of the system, e.g. the security model is correctly designed and implemented.

Moreover, I see some additional points to review in the original demexp design:

  1. Drop the literate programming approach. It is too costly to maintain (it is heart-braking to remove some code, but its even more difficult to remove some documentation). Some well defined documentation for the tricky parts or the global overview of the system would be enough I think.
  2. Traceability. From high-level specification to low-level one, down to code and its tests or proofs. As for safety critical software, maintaining traceability would bring a cleaner view of the system and it would help code reviews (one can dream! ;-) ) and show the software meets its goals.
  3. Focus on smaller goals. The overall objectives of demexp were very ambitious and thus difficult to reach. One should probably start from less ambitious goals, but try to make useful software in small steps.

Regarding the use of OCaml language, is was probably part of the raison why we never gain much contributions. But OCaml is so nice to use! I would probably keep that part... or not. I currently some other interesting and somewhat confidential languages to look at. :)