Management: Team meetings always went rather well. We seemed to have more success during our own team meetings on Sunday that during the lab sessions. In most meetings the action items got completed in a timely manner but our organization could have been much better. Sometimes it was difficult to organize six different people doing six different actions. We then get into the next topic of communication and coordination.
Communication / Coordination: We saw that communication between team members was the most difficult part of this project. One example of this difficulty in communication occurred during the thanksgiving break in which lack of coordination posed a difficult problem in getting the deliverable finished on time. Communication during meetings and emails were to the point and worked well but the lack of communication outside of meetings cause the greatest problem.
Group Dynamics: Overall the group chemistry was very good. We went through team meetings smoothly and did not have any significant problems. All group discussions ran smoothly and all team members were respectful to other team members.
Training: We had a couple of successfully training sessions but found that more in depth training sessions could have been useful in the overall software engineering process. This is especially true with respect to the networking skills. At first, all members of the team were questioned about their abilities in certain topics. After that, the most weak topic found among the group was the User Interface, especially with the use of swing, and networking. Two small informal training sessions were created to help enhance the understanding of each of these topics. Those session went rather well and had pretty respectable results.
Miscellaneous: We are very happy with our final design and stage 1 implemenatation. Our design was well thought out and crafted thoroughly. Overall, we didn't invest any significant extra amount of time. We only used about 10% more resources (time) than we thought would be necessary.
Management
Management was not a problem for this group. Since we were only a group of four people, our organization was very flat, meaning decision-making was almost always done by consensus. This allowed us to be flexible with assigning work to people, and one area our group did very well in was the distribution of work. When one person was assigned too much, it was common practice for another team member to step up and offer to take part of his workload for him. Things like this raised group morale and productivity. Another practice that made us more efficient was putting the action items on the web page after each class meeting, so everyone always knew exactly what he was responsible for and when it was due, and he could find that information online.
One area we didn't do quite so well in occurred when tasks were mentioned that needed to be done, but no one was specifically assigned to do them. An example of this was nametags. For the first four weeks of class we had an action item that said, Get nametags, but no one was responsible for it, so for four weeks we went without nametags. From the nametag experience we learned the importance of not only specifying what needs to be done but also specifying who needs to do it. It was a lesson that will be valuable in the future, and we are glad we could learn it early on from a simple thing like nametags, instead of not learning it until the end of the quarter and suffering for it.
Communication / Coordination
The small size of our group meant communication between members was not only easy, it was unavoidable. There was seldom anything that one person was working on that the other three did not know about. Email was our primary method of communication and we used it to send completed assignments back and forth, as well as post things to the web in places like our message board and the action item list. However the bulletin board crashed in the first few weeks of class so we mainly relied on email and the action list after that.
This team was excellent at getting the deliverables done before the deadlines were imminent. One of our goals at the beginning of the quarter was no all-nighters, and since we got all of our deliverables done with time to spare before the deadline, that eliminated the need to be up all night the day before something was due. While we all had certain nights when we worked later than we wanted to, the fact that we needed no all-nighters was very encouraging. The only time we even came close to an all-nighter was the night before stage 1 was due, and that ended at the reasonable hour of 1:00 AM.
Towards the end of the quarter we started using instant messaging to communicate back and forth. This was invaluable when we started writing code. Instead of emailing someone to clarify a question and waiting half an hour for them to check their mailbox, questions were instantly answered and confusion was kept to a minimum. We regret that we did not start using instant messaging sooner.
The one component of communication that was frustrating was the class diagram. When we got into method designing and then into actual coding, we began seeing mistakes in our design and fixing them on the fly. Most of the time we notified the designer of our changes, but sometimes changes happened that were never made public. Since we all used the class diagram as a central reference point, when it was wrong we didn't know it and confusion occurred. This was not much of a problem once we started using instant messaging but it was the one component in which our communication left much room for improvement.
Group Dynamics
As mentioned above, our small group size endowed us with a very positive group dynamic. Communication and coordination was easy, and one of the best parts was the ability of our group members to pass work to and from each other if workloads were unevenly distributed. Power was another thing that was distributed easily. For each component, the person who had the best background on the subject was essentially the unofficial leader for that part, and he delegated accordingly. We were able to keep our egos in check when another person gained control of a component and that greatly contributed to our positive dynamic.
The flat organization also helped our group dynamic, and so did the fact that none of us had really done a project like this before, so we were all in the same boat and we all learned as we went. We certainly learned as much from each other as we learned from the textbook.
Technical
The vast majority of our technical problems came from the GUI side of our program. None of us had done any extensive GUI programming in Java before, and so we had to learn a lot of Swing before we could apply that knowledge to the problem at hand. The back end code was pretty straightforward, as was the design, meaning the GUI stuff was easily our biggest technical hurdle. Not helping matters was the fact that although implementing the GUI front end was the most technically demanding part of the project, we allocated the least amount of time to it.
The most noticeable result of our lack of time spent on GUI code writing is that our algorithm to split up tiles and display them is very memory intensive and results in out of memory errors sometimes while the program is running. Future versions will have a more efficient algorithm for tile splitting and display, but for stage 1 there was just not enough time to redesign the algorithm with efficiency as the chief concern.
Tools
For the most part we were very satisfied with the tools we used to create our software. Each of us used either JCreator or JBuilder to write our code and comments. Those programs were shareware, easy to use, and well documented. Perhaps the most useful tool of all was java.sun.com, where we found tutorials and the Java API documentation. Microsoft Visio was also extremely useful to us during the entire quarter. We used it to generate a very professional-looking class diagram that was easy to update when needed. Visio also generated our class skeletons from the class diagram automatically. It even included javadoc comment tags. We used Forte to generate the code for our menu bar and the general layout of our GUI, and we were pleased with the visual components it created for us.
Our experience with tools was not entirely positive. While Forte did what we wanted visually, the code it generated was ugly and poorly formatted. Using it caused us to spend time afterwards going through our code, formatting and commenting it. In the end, formatting the code was easier and took less time than it would have to write the code ourselves from scratch, so using that tool was a good idea, though it was not without its drawbacks. The other drawback we had dealing with tools was when it came time to draw sequence diagrams. None of us had a good program to draw sequence diagrams. Visio worked but not as well as it did with the class diagram. We ended up using Publisher and Word to draw our sequence diagrams, but they don't allow saving as images, so we had to take screen shots and then manipulate them to create the finished diagram. This approach worked but there was probably a tool we could have used to make it easier on ourselves.
Training
Training was an area where our team did not perform as well as it could have. We developed our proof of concept and training plan early in the quarter. However, after that we got off track. We implemented the proof of concept on time and everyone had a good grasp of the concept, we chose to do networking for our proof of concept. Unfortunately, our stage 1 implementation did not include any networking at all. This is a prime example of not using our time well. All the time we spent on our proofs of concept could have been better spent on some part of the project that was relevant to our stage 1 work.
The training plan we developed was created early in the quarter and included some components that were overly simplistic and not totally relevant to our stage 1 issues. So as the 10th week approached, we decided to forgo completing our training plan and use our actual implementation as the proof that we learned the concepts we would have learned from the training plan. Had we actually implemented the training plan, we would have learned a few things that would have helped us for the implementation, but looking back the simplicity of the training plan really would not have benefited us very much so it appears that forgoing the training plan was the right choice after all.
Other
Looking back, we spent too much time on design. We ended up changing roughly half of what we designed initially, and if we had spent less time designing things that were to be thrown away later we would have had more time to tackle our technical hurdles. However, it is important to note that if we hadn't had that initial design to work with, we would have had a much harder time seeing what we actually needed to do to implement this project. So it is difficult to determine whether our surplus of time in design was worth the effort. Probably it was, and next time we do it we will be able to do it better the first time.
Tying into the theme of too much design and not enough implementation, it was a very bad idea for us to leave the GUI implementation to do over Thanksgiving break. We had no team communication and little motivation to work on our modules while at home in vacation mode, and the result was a rush to finish in the two days before stage 1 was due. We didn't really have a choice about the Thanksgiving assignment due to the timing of Thanksgiving, but we should have been looking ahead and known this would cause a problem and taken steps to avoid it.
One of the ways we could have avoided the Thanksgiving crunch would have been to start implementing the GUI in the weeks before Thanksgiving, allowing us to go slow, take our time, and fully understand everything we did. We should have done the non-GUI back end stuff last, since it was much more straightforward. Although we were inefficient in this class, this experience will allow us to plan better in 309 and in all of our future projects.
One prime example of wasted energy was our Data Dictionary. We created one early in the quarter, and when we went to update it during High Level Design we had to make so many changes that we ended up throwing the old one away and starting over with a new one. This means that we completely designed and implemented something twice that we never actually used as a tool during development. We instead used the class diagram as a reference, and although the Data Dictionary will be useful to our customers, we should have waited to write it until High Level Design because we never used it before then.
The last issue is something that was very frustrating but something that was probably unavoidable. The overall design of our program during the design stage bears little resemblance to the design of our program in its stage 1 form. We just didn't know enough about how to actually solve the problem statement during design, and that led to a design that was not thought through completely. This probably happens with most, if not all, new projects, but even so it is unfortunate that we did not see this coming so that we could make an effort to avoid it. However, now that we are familiar with the difficulties inherent in designing software from scratch, we should be able to use this knowledge to be more effective designers in the future. And learning how to diagnose problems and design more effectively is probably the most important skill we could have hoped to acquire from this course.
Conclusion
Building a product from scratch and implementing it in 10 weeks
seemed
like a daunting task back in September. We expected that we would
be in for a lot of work, and we were not disappointed. But we
also
learned an enormous amount about programming, software, software
engineering,
requirements, design, implementation, testing, and computer science in
general. We learned things in this class that we will be able to
use for the rest of our lives, at Cal Poly and in the real world.
We became better programmers, better team members, and better software
engineers. The lessons we learned in this class are lessons that
the programming world would do well to learn, but now that we know them
it is our duty to spread the knowledge. The wise leader does not
know everything. We, too, do not know everything. But after
this class, we are well on our way.