This is a very interesting notion for me this pair programming lark. I have done many small scale projects (mainly in php and involving output to HTML or MySQl databases, but thats an aside), but none that truely involved pair or group programing. Working with others, sure, but not actually programming as a team.

On Wednesday last week I sat down with Dan in the lab and with a blank text editor screen we went about writing a simple python program; read in data from a file, perform selected calculations on it, and ourput the results to another file. What was intersting is the night before I had read a chapter on the concepts of pair programming, and within a few minutes of working as a pair started noticing all the benefits the chapter had mentioned showing through. Things such as spotting each others mistakes, it being obvious when to change who has control over the keyboard, and sharing the enjoyment when something works, but having more support when it doesn’t along with better ideas for solutions.

I could certainly get used to it thats for sure, after all what small scale developer hasn’t been up at 3am staring at their screen wondering why something won’t work, but as soon as they get an e-mail in response to their issue from their co-worker about it the next day it’s blindingly obvious. Pair programming is like having that e-mail there immediately, but not only that, its a chance to step back from your own code and watch someone else work on it while you act as the external input. Its so many times better than sending “your bit” half way round the world and hoping it “will be ok” when you get it back with loads of code you don’t understand. Pair programming seems to allow you to both fully understand the code, while chomping through it quicker than if you worked on half and half.

I am however mindful of precisely what I mentioned a few lines up; 3am techie sessions (as I affectionately term them) have to be a thing of the past if you are to truely pair program. This will be fine initially, but obviously as deadlines close in, making sure you put the hours in as a team, and finding them for that matter, becomes increasingly important.

On the whole though, I can’t rate my initial experience of pair programming highly enough; for this project at least it looks certain to be a success

Had my first “meeting” with Dan today to discuss our SE12 python project. I place meeting in quotes because it was really lunch at the union, something we often do, but the subject of discussion was the project, so I guess it counts

Although it had been discussed before in passing we properly decided that the project would be to build an application to index and tag MP3 files. We started to outline the core aims of the project and discussed some of the main ideas we would/should draw on to achieve them. In the end, the following main aims of our final program were as follows:-

• Index MP3 files in a given directory, implementing recursive indexing, and reading the ID3 tags of the files as the index process progresses.
• Store data gathered from the indexing process (filenames, locations, and ID3 information) in a database rather than a flat file, initially using SQLlite, but ensuring the ability to change the application to use MySQL or Postgres easily.
• Allow incomplete or incorrectly tagged MP3 files to be manually corrected by way of a user interface. Search options such as finding incomplete files, or files named or tagged in a certain way are to be included to facilitate and improve this process

While these would form the basics of our project, many other ideas were floated, but not seriously considered until the complexity of the project was determined through prototyping or similar activities. They have not by any means however, been ruled out. These ideas consisted of:-

• Filling in gaps in tags, or re-tagging MP3 files completely using data obtained through file hashing indexed on a central server, such as freeDB or musicbrains
• Using a GUI interface. This is really a decided feature, but not something we have fully explored in Python. The idea of a web interface was floated, but it was decided a GUI was better and that the use of a database supporting SQL would facilitate the addition of a web based module at a later date were it required.
• Upon completion and marking the project will be released as open source, under the GPL
• Allowing an interface with an MP3 player through the selection of tracks by size (eg. you have a 4Gb MP3 player and you want a random selection of your music to be chosen from your library that will fill that size)
• The ability to select tracks in the library and generate XML based playlists containing those tracks on the fly for export to an MP3 player (software or hardware based). The format of the playlists was undecided, however the idea of using m3u or asx was mentioned.

That was all the project talk really, the only other major decision was to learn through practice and study, as much python as possible before commencing work on the project, especially in the areas where the knowledge was required for the project. This will mostly be done individually. Although the project will be pair-programmed, everyone learns differently, and if we both learn things that are slightly different or learned from slightly different angles, that will merely enhance our chances of success in a pair programming situation with respect to the actual project.

With respect to learning python, we both seem very happy with the syntax and the way it is implemented, and in a brief practice pair programming session in the lab today we managed to roll out code in just 30 minutes which in it’s self could be very useful later in the project.