There was not so much a question of learning as one of gaining experience. Some programming experience was gained, particularly as regards the Java invocation API, which was used in the management C client. Some system administration experience was also gained. In particular, the difficulty of providing good security was made clear. Also, the difficulty of providing users with needed access without violating the principle of least privilege presented itself (and was not resolved; root access was handed out almost like candy).
``Philosophy of management'' was an area in which much was learned. When this project began, it seemed (and still seems, to a lesser extent) that the primary burden for designing interfaces should be borne by those who implement and use them. That is, the primary role of management is perceived to be one of encouragement and judgment, not one of creation and enforcement. Teams needing to interface with each other need to communicate with each other. While management should be responsible for taking reasonable measures to ensure that needed communication takes place, it should not be an intermediary or middleman in the communication. However, it is now apparent that management must play an early and very active role in facilitating such communication, in order to overcome the inertia of the project's initial stages. Had this been done better, the final product might well have been completely functional.
The perception of the secondary role of management is the imposition of standards where a choice must be made between the conflicting requests of teams. For example, management implemented, among others, policies that cs519g1.csuglab would be a Linux box, that Java development should be done using Sun standard development tools, and that CVS would be used to maintain concurrent code updates. Management also requested that interfaces be documented and available several times over the course of the semester, without following up on those requests. It has now been graphically illustrated that management must actively follow up on such policy statements to see that they are observed, understood, and implemented.
The tertiary role of management, then, is perceived to be the active enforcement of standards and policies. Unfortunately, this role requires management to engage in behavior that not only requires very substantial investment of time by management, but is likely to be perceived as an unwelcome imposition by teams. Over the course of this project, such behavior would have included frequent (weekly or biweekly) meetings, and checking the code updates of teams to ensure that their code made progress and conformed to defined interfaces.