Programming Updates

Work continues on Genome, my multi-user music app. I've revamped the network code and I'm currently taking a look at the big picture - both to see how I can make the code more simple and easy to understand and to help remember how everything works. Returning to a large project after being away is always difficult, especially for one as large as this - it already has nearly 200 source files. Fortunately, most of the classes are small and focused and I used design patterns for many things so it's just a matter of refreshing my memory.

I'm trying to take some concepts used in XML processing, such as XPath commands and thinking how they can be applied to the song structure. The 'song' and (also every instrument in the song) consists of modules. Modules can contain other modules, so it naturally lends itself to a hierarchical structure, like XML. By making it so that individual modules can be accessed similar to the way that XPath commands work. I see this being useful for scripting - it would be interesting to allow people to build a custom interface that gives them the ability to send events to any instrument or effect in the song. They could lay down buttons and sliders and attach scripts to them that generate events like triggering patterns, notes or control changes. This is a feature that appeals more to experimental or live musicians so it might not be in the first version, at least but the hooks will be there.

I read a bit about Extreme programming (XP) yesterday, and I realized that some aspects of it are things that I already practice and believe strongly in. For instance, not trying to anticipate every possible use of a piece of code and adding lots of extra functionality. This only a) complicates the code and b) you can never fully anticipate the exact requirements so anything you write will probably need to be changed or re-written (so you end up wasting extra time instead of saving time). Doing the simplest thing first - I always do a 'first run' algorithm just to get it working and then worry about optimizing it or improving it later. Often this will help you see what needs to be improved far better than trying to anticipate it up-front. Plus if you are not afraid to change your code, you'll be less likely to leave something in that isn't optimal. Extreme programming is all about making constant refinements to the code. I also really try to make the code easy to understand - instead of adding lots of comments, think about how you can change the code to make it more understandable. If it requires a big explanation, chances are that what you have done is confusing. One thing I probably should do more of is Unit Testing. I usually make small changes and do functional tests immediately, but creating some test classes should save time and also help catch more bugs. I think the big theme of XP is not to overload your brain trying to plan everything out, but instead to stay aggressive and keep plugging away at the problem a little piece at a time.

The other big aspect of XP is Paired programming, where you work with another person. I think this can work well if both people are at the same skill level and stick to the ideaology of Extreme Programming. Otherwise, it's very likely that one person starts doing all the work while the other person gets distracted and starts playing with a pencil and some paper clips. Or, one person becomes the secretary typing out all the code while the other directs him.