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?
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.....
by nnp (not verified) on 12/2/08 at 1:13 pm |reply
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.
by BTC (not verified) on 12/2/08 at 4:51 pm |reply
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
by Joe Kelly (not verified) on 12/2/08 at 5:02 pm |reply
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!.
Sidekick: The Good News & the Bad News Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Surviving Windows is easier than you think… MKS offers the power of an integrated all-in-one environment and provides you with the Power of UNIX on Windows Learn More
Brought to you by:
Free books
We have 5 copies of these two new books to give to some lucky readers. The deadline for entries is November 30, 2009.
AISO founders envisioned a Web hosting company that was environmentally friendly. While the company employed energy-efficient innovations like solar panels, its infrastructure produced unacceptable power and cooling requirements. Find out how AISO leveraged AMD technology to overcome their challenge in this case study white paper.
In this whitepaper, Scalar explores the opportunity to change the landscape with respect to mission critical databases
built around Oracle. Leveraging technologies such as Linux, high-end commodity processing power and Oracle RAC
technology to architect, design, build and maintain database infrastructure that delivers maximum availability, reliability
and performance at a fraction of traditional cost.
On a typical day, weather.com, the Web site for The Weather Channel in Atlanta, serves up between 15 million and 20 million page views. But in September 2004, when back-to-back hurricanes ransacked Florida, the peak traffic on one day more than tripled: over 70 million page views by more than 7 million unique visitors. Read the full success story now.
jfruh
pasmith
Esther Schindler
mikelgan
David Strom
sjvn
Sandra Henry-Stocker
Quick, practical advice for IT pros. Made fresh daily.
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.