El Tramo

Although Psi has had a fair number of succesful Google Summer of Code projects so far, we have experienced some failures as well: the summer before last, 3 out of 6 projects didn’t make the final deadline. A project’s failure was typically due to not having anything really usable at the end of the summer, regardless of the good work that was done during the past months. To reduce the risk of such surprises, I decided to take an Agile Development approach for this year’s ‘Roster improvement’ project.

Here are some of the principles of Agile software development (as written down in the Agile Manifesto), and how we apply them to Adam’s GSoC project:

• The developer frequently delivers working software to the customer. In our case, Adam sends me a working roster every monday, which I can play around with. I then tell him what I do and don’t like about it, and he processes my feedback during the next iteration (i.e. the next week). Of course, since the roster is made from scratch, the backend of the roster is completely mocked up during the first weeks. As the project progresses, the backend will become more ‘real’. 
• Working software is the primary measure of progress. This avoids the kind of surprises we had before, where both student and mentor believed everything was going fine during the project, but where nothing could be delivered at the end of the project. 
• Code is kept as simple as possible: if you don’t need something, leave it out. By initially focusing on the roster frontend (while keeping the backend framework mocked up), we ensure that our backend will only be as complex as we actually need it to be. Moreover, we can constantly change our mind about the requirements throughout the whole project without having to throw away the complete backend. This contrasts with the previous attempts we had at reworking the Psi roster, where we started by working out a complex roster backend, but never got to the point where we had something working with this (over-)designed framework, and had to start over all again.
• Code is written with testability in mind. In principle, all new code needs to be tested (and preferably even unit tested before it’s written), which allows you to quickly refactor while remaining sure that your code still works as before. However, given the very strict time constraints, I’m not sure yet that we’re going to apply this Test-driven Development approach (although some claim that the extra time you spend in tests will even pay off in the short term).
• Good designs make sure that you can easily adapt your code to changing requirements. For example, a Model-View-Controller-based design seems to lend itself well to the roster, making the (rather complex) roster logic both testable, extensible, and easy to understand.

I’m convinced that these principles will ensure that both Adam and I (and of course all Psi users) will get a succesful result at the end of the project, and that we’ll have had a fun time during these 3 months.

Tags: Agile Software Development, Jabber, Model-View-Controller, Programming, Psi, Test-Driven Development, Unit Testing, XMPP

This entry was posted on Thursday, June 26th, 2008 at 21:07 and is filed under Psi. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.