Tomorrow never knows

I've been reflecting on a bit of code I've had to write recently, and it's got me thinking about how far ahead one should think in designing things - whether it be software (as with me) or anything else..

For a current piece of work, I have inherited a code base which is well suited for its intended use. It doesn't appear to have much fat/ bloat/ unneeded features. It has structure, it has an apparent internal parsimony which holds it together as one would hope. The user interface of the software is primarily mouse driven, and as such the controls are well set up for the various interactions that the modern computers tend to offer when it comes to pointing devices - move over, clicking with any of three buttons, mouse wheel support, etc.

A new feature was added just before I got the code, something that required accepting keyboard as well as mouse input. This is cross platform code, supporting Apple Mac & Windows. The Apple code was working as hoped, but the Windows code wasn't. So I went to have a look.

It was very clear that the keyboard-based enhancement given to the Mac side of the code was very much an afterthought - something bolted on to the fairly tight code that was already there. It stuck out, not in an ugly fashion, but like a new extension on a house where the bricks haven't been matched to the original structure. The corresponding Windows code had not been written at all, and so my task was to write it. The nature of the framework/library presented certain challenges, based on how the original code had been designed. It had been designed with just the purpose of getting the job in hand done (that is, mouse based input), and so weaving new functionality was not as simple as it could have been if there had been an eye kept open to the future.

My observations are not a criticism of the original developer (be they one or many), but more about the nature of what should be included during the design phase of a project.

The term 'Agile' has been a buzzword in many circles for a number of years, and software development has not been shielded from it. In software it frequently manifests itself as a strategy for getting done only what needs to be done at a given time, and if needs change in the future, then you just adapt what you did previously. There is some sense to this - why prepare for something that may never be needed?

I must confess, I've never been totally sold on the whole 'Agile Development' thing (with a capital 'A'). Being 'agile' (lowercase 'a') seems a good idea to me - being able to respond quickly to change, and building the tools & libraries with which one can meet those challenges looks like reasonable sense. But an ethos of 'do today what you need today' often comes across as a little shallow. Does it work, or does it just commoditise development in an unhelpful way? Many places seem to swear by it, but it's largely the developers who blow that trumpet: might I suggest that there's a hint of MRDA about this - they are the ones who benefit the most, since (perhaps) it is a way of ensuring longievity of employment, as "built-in obsolescence" doesn't really factor with software in the same way that it does with physical products..

hmmm.. Getting a little sidetracked here, I might return to that topic another day (I might not).. However, the question remains - to what extent should one have an eye on the future when making something today?

When a carpenter designs a standard rectangular table, should they make allowance for a possible fifth leg to be added? Would experience suggest that this may be rather pointless excercise?

When purchasing land to build a road, should allowance be made in advance for potential escalation of traffic numbers and the possible need for future widening? Would experience suggest that this may be a prudent thing to at least explore.

My guess is that it's the 'experience' which would dictate these things. Carpenters will generally have some idea how many legs will be needed to support the weight of wood they have before them. Transportation Planners have access to all kinds of statistics of traffic flows & growth rates for more types of road than any of us could be interested to know existed. Based on my time sat writing software I know that, had I been one of the original designers of the library I have been working on, I would have put in some provision for keyboard input. However, I may have well been very wrong to do so, since experience of this type of product would suggest that it was an unnecessary design feature (given that it's a totally mouse driven environment in over 99% of this niche market), and I would be putting fat where it wasn't needed.

It would have made today's job a lot easier though.

The past comes calling

One of my favourite corners of the internet, known as KvR, runs various competitions.

There is a monthly writing comp in which a piece must be written & recorded within certain defined boundaries (mostly a limit to the length, must stick to a given theme, but occasionally others). The first three weeks of a month are devoted to the writing and recording, then the last week all the entrants (and other forum members) vote on the pieces to decide a winner. I've never won, but have entered many times through the years; generally there are 50-70 entries. Worst I did was last, best was 4th, generally I'm in the first quarter. I do it more for fun than chart position. Some of my entries can be found here.

KvR also runs 'Developer Challenges,' where independent developers get the chance to enter a new creation each, and the community gets a ton of new free stuff! There have been three (DC06, DC07 & DC09); I (both uniquely and cheekily) have entered 4 times.. I have faired averagely, which I don't mind; the things I have written have been devised & created during snatched moments and so their ranking is probably a fair assessment. However, they have garnered attention away from the arena of competition, being recommended by folk at varying intervals. This has been very pleasant. From checking server logs (in the way that one does), I have found a new reference to my DC09 entry 'SynecDC.' It's from the myvst website and can be found here.



I enjoyed making SynecDC, and there is an idea for a big brother to it which will add further modulators; but it's not coming any time soon! My favourite patch is "DragonCity" which can be heard at 1:29.

Heck is other people's code

It's been a couple of weeks since my last post, so whilst Bill Bruford's Earthworks captures my aural attention, I will vent a little about one of the main hassles that can beset a jobbing programmer - received code.

I am currently engaged in 3 projects (yay! I have some work!), two of which are longer standing than my recent redundancy. But all three are causing me grief in one way or another...

In most lines of work, one can generally pick up where another has left off. One will mumble and grumble about certain things that have been done before, or be pleasantly surprised by other bits of what is found. A clerk might despair of their previous incumbent's filing incompetence; a solicitor may be pleased to see the last person to touch a case made a note about an often overlooked piece of law; handymen will often have little praise for the last person to lay hands on the items that they have been called to 'fix.'

Software is little different from any other discipline in this respect. When one starts a new project, or returns to work on something that one hasn't touched for a long time (even six months can be a long time in programming), there can be many "err.. Qu'est-ce qui se passe?" moments (I'll refrain from the more common exclamations..). Equally there can be a number of 'oh, that's pretty neat' epiphanies, but they are generally fewer and farther between.

So I have three projects. The latest I have received generally seems of a reasonable standard, and certainly does what's its supposed to (it's code for two products which have been on the market for some time); however, getting the thing to compile on the various platforms for which it's specified has been a challenge, and one I have not been able to get through without some very gratefully received help. Most places I have worked, the received code will at least have the decency to be able to construct itself if you tell it where to look for its component parts. Alas this one has been an uphill struggle; it's almost there, but not totally done yet, hence taking a break to reflect here just to regain some clarity.

The other two projects are conversion projects of work I have previously undertaken (MIDI Madness and a vocal plugin written for the NTrack software studio). Both pieces of kit work well and are 'in the wild', but the respective clients asked me to make them available for the Apple Macintosh [a 'mac' for those unaware of the history ;-)]. This has meant a complete ground-up rewrite for one, and a switch of libraries for another. Dealing with my own code is alright, here and there I notice things and wonder what I was thinking, (let's call it a 'QQSP' moment, or maybe just 'QSP' for brevity); but getting it to grips with yet another person's (or company's) idea of how something should 'work' and how I can stitch something that was perfectly solid onto can be.. well, a long and quite windy road. The odd thing is that at the end of the day, both these projects will just do what they did before!

Right, well, back to it...

Reading week

Today (well, yesterday, it's actually tomorrow now), I had a very nice time sitting on a train reading (book, magazine, newspaper, in that order) & doing some listening. I will write about some of my recent listening in another post.

In between journeys I met up with some very pleasant gentlemen in Reading. I was hoping to meet Tiny & Keyop, especially Princess.. even 7zark7, but alas no, they weren't there. The very fine fellows have asked me to do some work with them. At the  moment it will be a week a month, but it's exactly what I want to be doing. I know that not everyone who reads this will share my views, but I see this as an answer to prayer, and I feel very blessed by the day, the attitudes of the chaps, and that very nice lunch they took me for. Oh and the chance to fiddle about with some fantastic and rare old gear :-)

Tomorrow (today - see above) I meet with my local Job Centre. They will, no doubt, ask what I will be doing the other three weeks of a month.