DueDates project, a first taste in multi-developer coding

Coders don't play nice with each another
From the moment we started taking ICS courses, we were told by our professors that if we use someone else's code for our assignments, it constitutes as plagiarism. As a result, the easiest way for us to prevent against this is to not share our code with others in the first place. Maybe this is the reason why so many ICS students seem so anti-social, it's all because they want to keep their code to themselves!

Luckily, our ICS 413 class aims to break this viciously bad habit because, in the real world, not sharing code pretty much means not receiving a paycheck. To help us learn that sharing code and collaborating with one another is a -good- thing, we were assigned to implement a simple program. All it had to do was check to see if we had any borrowed books from the UH library system and print it out to the console.

Every beginning...already has another beginning
To facilitate this process, our professor provided us with a Java class that uses the HttpUnit library. This library (and supporting libraries, since it relies on other stuff too) allows developers to use 'screen scraping', which is a shorter and smarter-sounding way of saying "parse HTML, automatically fill out form fields, and submit it". The Java class he gave us started us off by providing methods to log into the UH library system and pull the borrowed books data from a table. All we had to do was program it so it could be run from a console using arguments.

I'd like to order Subversion for two, please
Previously we played around with Subversion by ourselves, but this is the first assignment where more than one person had to actively work on a single project. I worked with Aric West on this project, and it was definitely a much different experience than coding individually.

We managed to implement the requirements, but not without some significant difficulties. All the lessons learned about creating test cases and planning out your project before you even begin to code really hit home. At first we decided to do a quick-and-dirty implementation to test the code that our professor gave us, but after that we decided to just expand on it since it was already written and working. This is where we should've done things differently. Although we tried to write it initially with modularity in mind, we should have first planned it out thoroughly because some parts of it required almost a complete rewrite. For example, I was tasked with creating a command line parser class. Although the class itself was pretty easy to write, the hardest part was making it play nice with everything else and I had to modify every other class to support error checking for the parser class. This problem could have been mollified if we planned out our project structure before we started coding, and although it was small enough to handle for a small program with only two developers, it's easy to see how it can become a HUGE problem when you have to tell a big group of coders "Hey guys, I need to update 20 classes to support mine because we didn't design things properly." Not exactly an efficient way of establishing good co-worker relations...

Also, just like there are different literary styles when writing a book, there are also different styles that people use when they code. Aric wrote some code that got the job done, but I wasn't a big fan of how it was written, even though there was nothing wrong with it. The control freak in me wanted to change everything around to how I wanted it to look, but I had to suppress that urge and just accept it as an alternate road leading to the same destination.

Don't call me, I'll call you
Our professor stressed that we should meet up for at least 30 minutes each day to work on the project. This is easy to do in an office environment; walk over to the other guy's cubicle and strike up a conversation with him. As students though, it was much harder to do because of conflicting schedules, difficulties in transportation, or even something as simple as finding a place to meet up at. As a result, we were only able to meet up for the first two days of the project, and we made the most progress in those two days. After the first day we already finished the quick-and-dirty implementation, and after the second we managed to modularize a big part of it. However, after that things kinda fell apart and we lost communications. Neither of us worked on the project again until the day before it was due and we could only collaborate online. Even then, that was a much different experience than in person. There's just something about working with someone else next to you that really motivates you to get the work done and avoid all distractions. Since I'm assuming that this project will continue on in the future, I'd definitely try to meet up with my group members more often, though it might become harder as the number of people increases. Still, the advantages far outweigh the hassle of synchronizing everyone's schedules, and after this project I'm sure everyone else will value it highly too.

You can read me like an open-source project
Open source development is an interesting way of working on a project. Normally people who are working on a project also see each other in person or are in the same company, but when an open-source project gets put online, there could be any number of developers from various locations, and there isn't so much a development team as there are just contributors. Hence, there need to be tools so that people can keep track of the project's progress. Luckily these tools do exist, and Google Project Hosting does a pretty good job of providing these tools in one consolidated package. It offers SVN access for both visitors and developers, a wiki to store relevant information, file hosting, and an issue tracker to delegate out tasks. However, it's not perfect and lacks in certain features that I'd personally want to see. One thing in particular is that I'm not a big fan of how you can't edit anything once it's been committed, and a history of all the changes is always kept. Nice if someone comes in and destroys all your data, but not so nice if you made a huge spelling error or posted something stupid. A feature to be able to edit or remove your changes within 15 minutes of committing them would have been nice. Overall though, Google Project Hosting is pretty awesome given that it's free and offers pretty much everything someone needs to maintain an open-source project.