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.
Build your tech library with our book giveaways.
Hacking Exposed, Sixth Edition
By Stuart McClure, Joel Scambray, George Kurtz; Published by McGraw-Hill/Osborne
The original Hacking Exposed authors rejoin forces on this tenth anniversary edition to offer completely up-to-date coverage of today's most devastating hacks and how to prevent them. Using their proven methodology, the authors reveal how to locate and patch system vulnerabilities. The book includes new coverage of ISO images, wireless and RFID attacks, Web 2.0 vulnerabilities, anonymous hacking tools, Ubuntu, Windows Server 2008, mobile devices, and more. Enter now!
Are you serious?
I'm at a loss for words. Anything more complex than a 'Hello World' is going to require some form of elementry design before implementation and given that, you're basically back at an iterative development process.... as people have been talking about for years.Either you've no concept of what is actually involved in design/implementation or you're merely trying to look like you've some wonderful new insight when all you're really saying is 'Iterative design and implementation is useful'.
Bloody hell.....
A place for everything, and everything in it's place...
Take it easy. There's no need to find a procedural dogma. Different situations and different clientele call for different approaches.I have clients who are tremendously organized and get nearly full interactive designs in place up front. On the flip side, I also have clients who have a more vague notion of what they want because what they're asking for is unusual or different than "canned" alternatives are designed for. In these cases, implementation first is a good option because it gives them something with which to begin a more interactive and in-depth design process.
To boot, not all design teams are created equal, and sometimes, implementation uncovers design holes. Loosen up, man, there's more than one way to skin a cat.
Definite value in this
I have some experience with this approach, mainly in the Business Intelligence area. I am an internal IT resource and time is very limited. I do not get the time, budget or most importantly, senior head space, to do a serious, in depth eval of veru new and ground breaking techniques or products.The approach I have used is the one Sean has outlined. I implement a close to Out of the Box version of the solution, in my case an Analysis Services Cube of our sales. I showed this to some key opinion shapers and they then drove the process to get me my budget, resource and management engagement to take on a proper design and subsequently much more robust implementation.
JK