December 01, 2008, 8:28 AM — If I were to utter the two words "implementation" and "design" in the context of an IT project, would you be inclined to re-order them in your head? I.e. to think in terms of "design" first and "implementation" second?
If so, you are very much in the majority. There is a volume of received wisdom the size of the Mariana Trench which dictates that design comes before implementation in IT projects. The received wisdom is being challenged somewhat by the agile development movement which takes the view that design and implementation are best interleaved rather than serialized.
I have a lot of time for this agile view. However, as is often the case, it can be taken to extremes and the results will not be good. The old way is not "wrong" in any black-and-white sense. It is just that the old way is more like a special case of a more general way of doing things. I.e. design and implementation can be interleaved. So, you could proceed like this:
project = (design THEN implementation)
or you could proceed like this:
project = (design THEN implementation) THEN (design THEN implementation)...
But could you do this?
project = (implementation THEN design)
Woa! That looks like a weird combination. Would you ever implement and then design? What does that even mean?
I think the answer is, yes, you can sometimes do that and I can see two equally useful reasons for doing so, as long as a subsequent implementation phase follows. In other words, I think this can make sense:
project = (implementation THEN design) THEN implementation
but this is just playing games with words:
project = implementation THEN design
A design phase, wedged between two implementation phases makes sense if you are doing rapid prototyping. That is, you build something, learn from it and use the experience to create a good design for the real implementation, throwing the prototype away.
It also makes sense in information modelling where the best way to categorize, classify and organize data only becomes apparent as the volume of data under management reaches critical mass. In that situation, you do not have the necessary information to do the design up front.
A common example is the humble timesheet. You want the reports to be meaningful yet you cannot know in advance what task decomposition is going to make sense as projects evolve. What to do? You could wire a set of task codes and hope for the best. You could make the list open ended and hope that tacking new codes on the end during use will suffice. Or, shock horror, you could leave the task coding free form. Let users decompose their tasks in whatever way seems natural to them and then later, formalize them and categorize them based on actual data from the running system.
This is an example of design following implementation. Far from being anathema, the idea is a very powerful one, especially in information modelling. Taken to extremes of course, the results will not be good but in moderation, it will serve you well.
