When you’ve been studying in compsci long enough (or if you’re just really geeky), certain aspects of it begin to spill over into other aspects of your life. It quite literally changes your way of thinking. Most of you will know what I’m talking about it: have you ever stood in line at Tim Hortons and tried to figure out how to get coffee in faster than O(n) time? If not, then get cracking, I need that double-double! 
So when it came time to do our first CSC302 assignment, we decided to apply the divide-and-conquer algorithm for task allocation. Our job for the first assignment was to take a look at the JFreeChart library **yawn** and reverse-engineer some UML diagrams to get a feel for the project.
We broke down the assignment into three parts: class-specific UML diagrams, high-level UML diagrams/software architecture, and identifying software design patterns. We only have 5 people in our team, so we split up into two sub-teams of two and a “team” of one. I say “team” because I don’t think you can be a “team” with only one person…
The first sub-team would do the class-specific diagrams, the second sub-team would do the high-level/software architecture diagrams, and the last team member would identify the software design patterns. Why did we do it this way? Well the idea was that, even with reverse engineering tools, the UML diagrams and explanations would be the hardest to do. Once those were completed, we would have a pretty good roadmap of the project and the task of identifying software design patterns would be simple! Once the sub-teams were done with their tasks, we would merge all our work into one beautiful, insightful report about the intricacies of JFreeChart.
Of course, things didn’t work out as planned.
The first problem that we encountered was a matter of pure information overload. Quite frankly, UML tools suck. UML reverse engineering tools suck even more. UML modelling tools for identifying high level architectures and package interactions are rare, if not non-existent. So a lot of time on the first part of the project was spent on figuring what to tools to use. Once we figured that out, the UML diagrams that came out were mostly garbage; they were jam-packed with unnecessary information and required major clean-up.
Because of the extra time that was required to generate the UML diagrams, our team got completely backlogged. For some of the diagrams, we did manual clean-up. For others, we quite simply did them manually. This left us with very little time to do the individual write-ups, merge the write-ups, and then try to edit it all in attempts to make one coherent report. So much for the land of milk and honey.
Lesson learned? Plan for setbacks, plan for failure. When it comes down to figuring how large software systems work, more brains and more eyes> divide and conquer
And as we sat in BA2210, furiously trying to finish the report, we had one last question to answer: What do we put down as the team name for the report’s cover letter?
We quickly decided on Team IFHUML — I Fking Hate UML