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 main problem with Agile methodologies is that they don't tend to scale well... We tend to favour a blended approach where I work - we have several days of planning workshops in which we nail down the problem domain as best we can according to the business case, with everyone in the project involved, and then split into teams to do the actual implementation.
ReplyDeleteSometimes this works well, and sometimes it doesn't - small projects tend to benefit from it, whereas the larger, enterprise scope apps tend to flounder a bit.
The thing tends to be cherry picking the bits that work well, as opposed to picking up the whole methodology and taking it as gospel - co-location, for example, works well in every situation, since it enables implementation of individual features / stories in a project to be approved as soon as they're ready to be demonstrated to the business, which is great for minimizing turnaround on stories, and for getting realitime feedback, instead of delivering a full unit of work and waiting weeks to find out if it's what the users actually want. Likewise, involving the business in the planning meetings for each iteration of development, and having them pick which top-level features they want next is a great way to get them to take responsibility for their own requests, since that way they know exactly what's being worked on, and feel like they've been involved in the actual development process (saves a hell of a lot of complaining later on ;)). Other bits of Agile, though, such as TDD are only really suitable on small projects - Test Driven Development decreases in usefulness in direct propertion to the size of the project. Requirements in TDD projects tend to be emergent rather than pre-defined, which leads to frequent refactoring, yada yada, and the more code you have to refactor at once the more likely it is to blow up in your face...
Of course, it doesn't help that the definition of what "Agile" is seems to change every other week lol The latest buzzword around my office is "Kanban" (google it :)) - a process of work allocation based on the factory lines at Toyota, and it works fabulously. There's no guarantee that something else won't be found to work even better next week though ;)