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.