If only I'd over-engineered it!

Sometimes you come back to an application and can only weep at the lack of foresight which would have made implementing the required new feature a doddle! But you've no time to weep, just as you had no time back in the day to make the application dance to any tune imaginable. You also know that Agile methodology tells you to code what is needed and no more and yet, you're always asking yourself, wouldn't it be nice if you could predict the future and just squeeze in that little bit of extra abstraction? In my current predicament, I can honestly say that there was no way I could have imagined replacing the source of my real-time feed with a completely different API. And given that the new API is only intended for an internal audience, with perhaps the odd external client demonstration, was it really an oversight? Afterall, making the receiving code abstract enough to cope with a simple replacement of the input feed took two weeks, time I simply didn't have on the original project. And yet, was there anything I could have done that would have made my life simpler now without comprimising the original deadline? In fact, I'm going to propose the following guidelines (admittedly Java centric) to help compromise between over-engineering and delivering what is needed now:

• Always code to interfaces. This is extremely obvious but, yet again, the last API I worked on hadn't and the resulting experience was painful to say the least. However, there's no need to create interfaces for objects intended as data containers.
• Use dependency injection. That is, keep coupling between classes light and ask yourself if creating an object is necessary in all cases. Inject it if at all possible.
• Use factories. If an object has to be created, consider using a Factory object to create it instead. This can be as simple as a method on an Enum specifying the various types and associates a creation mechanism with each one.

There's nothing new in these suggestion and I'll keep adding to it as and when.

You need an architect ...

Having worked on two projects recently, both of which had become distressed and each embracing very different design methodologies, I thought it'd be interesting to look at what went wrong in each case. The first project started with a "top-down", architectural design exercise which was later implemented by another dev team. The other was a "bottom-up" proof of concept exercise intended to deliver demonstrable functionality in a short space of time with virtually non-existent design effort. The top-down project produced a set of grand sounding documents specifying, in some detail, the desired (SOA) architectural framework and an outline of how the first pilot application should be implemented. The bottom-up project resulted in code.

On implementing the top-down project's pilot application, the visionary plans got lost in the process of making sure the required functionality was delivered on time and on budget. Unfortunately, when it came time to add another application to the framework, the owners found that their cost-cutting meant that all the services created to support the pilot app couldn't be re-used for anything else. The bottom-up project, on the other hand, hit the keyboards from the start and produced a tangled code base that didn't come close to delivering anything, on time or otherwise.

The top-down project lost its way as the lauded design principle - to separate services from the presentation tier - wasn't properly considered in the frenzy to get code out the door. The bottom-up project similarly went wrong as there were no design principles at all, leading to confused and broken code. In both cases, common functionality for use across many use cases simply didn't exist. Although each project had started from a different position, both ended up with the same problem. It seems to me that the missing ingredient in both cases was a lack of direction during the development phase. I was left wondering why such a crucial resource - architectural guidance - had been left out. Although it seems to me that the upfront cost of some form of architectural oversight will pay for itself in a very short space of time, it'd be interesting to know how to convince paying clients!