Deployment Experiment Reflections

From ZenWiki

Reflections on Deployment Experiment

By Mnovakou 04:43, 26 February 2007 (EST)

Major Points

1. When the experiment scope was determined, little thought was given to what the outcome would be. As such, Allen was disappointed that at the end all I had was open questions, no concrete information to add to the architecture. This is a valid concern. I believe that the reason this happened is because the scope of answering the questions asked during this experiment was greater than the experiment timeline allowed for.

• Original scope:
  • Write the startup process and show that you can connect to a database via JDBC, and recognize when a login has been accepted or rejected
• Resulting questions:
  • Should the logins on the ZEN Client be coupled with the logins on the ZEN Server?
    • Decision: No. Coupling the logins not only requires significant extra effort but also represents a security risk.
  • Should the ZEN Client be structured with a startup process calling a main process only if the login passes?
    • Decision: TBD. Probably yes, but ensuring that this is technically feasable is the point of the follow-on to this experiment. If it is feasible, it provides a single point of access which ensures secure startup of the main process.
  • What should the data store on the ZEN Client be?
    • Decision: TBD. Options are normal MySQL DB, Embedded MySQL DB, and flat file. Normal MySQL DB has potential security issues locally. Flat file could result in data integrity management problems. Therefore, leaning towards Embedded MySQL DB. Follow-on experiment should examine this.
  • How should we manage the login data in the ZEN Client?
    • Decision: TBD. If a MySQL database is used (see above) then use of the native MySQL login storage would be ideal.

2. When choosing an experiment for which the experimenter has no experience, it is important to schedule in a significant amount of time for research.

• This is necessary as the experimenter will need the time to learn and understand the technology.

3. The experiment process (what are the artifacts created, what meetings are undertaken, etc) should be well defined prior to engaging in the experiment.

• My impression was that the process was essentially made up on the fly as team members decided to perform reviews or incorporate changes.

4. The vertical approach in performing experiments is interesting but can incur a great deal of overhead in learning. With that said, I feel that the vertical approach provides a great deal more concrete data in making architectural decisions, because the details are looked at much more closely by far more eyes. Had we chosen a horizontal approach with only 1 person working on implementation, I don't think we would have made nearly as much progress as we did, even disregarding some of the failures we did encounter. As it is, although it was very painful, we have experimental code working for the UI, the status, the question entry piece, and the server login. In my mind, while it would be difficult to compare our experience with a horizontal approach at this point, I feel we are at least as far as we would be had we taken a horizontal approach. Therefore I feel it was a useful, if painful, methodology to engage in.

Minor Points

1. It is important to not take criticism on experiment work personally. I was defensive during one of my reviews, which was bad. I will ensure that I take all criticism constructively in the future.