Lessons Learned:

Computer systems should not be trusted. Many things can happen to a system and they should not be considered reliable. Such examples experienced on this project were: system crash, file system structures are whipped out, some systems require assistance to come back on line, connection can not always be maintained.

Requirement and Design phases of the software development process can not be over looked or handled haphazardly. There were many features that were designed to be implemented, but many did not reach the coding stage. It is important to take time to do specifications and requirements documentation. By creating these forms of documentation does not allow many things slip through the cracks. They also allow the project to be defined more clearly. It does not allow anything to be over looked. Every thing is laid out in black in white. I was constantly looking for references on how many components should be created or function. It was also difficult to create the formal design documentation without any guidance besides from the brain storming session the team held. This was the first time I was truly able to see how the software models and software life cycles worked. Being able to follow both assists with the project to make sure it runs smoothly. Many of the programs I have written in the past, the appropriate documentation was given to me by a professor or was informally defined in my mind.

I learned that as a programmer you must be very flexible and versatile. Use your resources when you can and when you can not, be creative. Creativeness will occasionally provide new ideas and means to attack a problem even though it many not be the right direction..

One of the most important things I learned was how to work as a team member. Up until this point, I did not know or had previously experienced this . This idea is rarely promoted in an academic environment, where it is crucial in many industrial environments. This brought 6 complete strangers together and produced a pretty good working team, which produced a software package in only two and a half (2.5) months. As individuals, the project would not of gotten as far as it did. The team supported each other. Team members assisted others to over come difficulties when they stumbled into dead ends. Constant communication is one of the key features to work as team. The 400+ pages of electronic mail keep each team member up to date on what the other was doing and what modifications were being made. It is my opinion the constant communication assisted in making the team more efficient and productive. It took only minutes for the team members to get to know one another and team roles to be handed out. The team utilized everyone experience and background to the team benefit.

One additional factor learned is even though you do not think anything will happen to your source code always make backups. There were several times where the version control that I maintained for the team came in handy. The version control made backup up copies of files when a user added a new file to the version control system. I also made regular backups of the database. Backup up the version control database came in handle too. There were several time through system calls and location of invocation of the scripts the database would get corrupted for some unexplained reason. At times I literally had only minutes to fix the database in order to make integration work. This way if any changes were lost when the file was updated, the lost code was saved. Also in case team members were modifying code and accidentally made changes without realizing it importance and could not return to the original code. The original code is always preserved in version control. And finally off site or remote site backups are good to maintain. This point proved itself when the sun cluster the team was working off of experienced a damaged disk.

The one thing required for me to learn in order to complete this project was the Java Language. I had background in C++, so the language was easy to learn. I feel the Java language focuses more closely and/or enforces the object-oriented concepts. Java is an in creditable language. The class hierarchy and contents are well defined. The classes demonstrate magnificently how source code can be reused. The Java class hierarchy illustrates the great advantage of inheritance. The Java language has the potential to become the most popular and wide used computer programming language.

Written By Graham L. Mehl
Last Modified on April 23, 1996
© Villanova University