Implement first, design later

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

do not agree with sean

Hello All, I have to agree entirely with the very first poster. I am sure the article was written with the intent of 'getting a reaction' (intended in a positive sense, make people think). That said, I do not think there is any basis of fact or any grounding of reality in it.
This 'iterative' process in my experience of software engineering is often associated with badly organised, poor quality and and late projects. Let us be clear, we are all passionate about IT and different ways to do things. In the real world 'real artists ship'. You must deliver on time and on budget. I do not believe this mishmashprocess allows an IT project an adequate facility to plan its scope, impact etc...
Of course, IT projects need to be flexible too, and perhaps this is where Seáns original article idea stemmed from. It would be wrong to assume that each and every IT project will have a period that only does design, a period that only does test and period that only does implementation. Of course the corners of these stages will overlap. They have to. But a formalised approach to sign off and delivery at each stage is imperative to a quality end product that actually ships!.

No way

This is a nonsense type of standpoint from someone who is not under pressure with bug budgets.