views:

106

answers:

6

How do you differentiate between design decisions vs implementation decisions ?

To give a specific example: We are developing some web services which will integrate our application with another One of the question I asked was- do we want the integration between the two applications to by asynch or sync ?

Someone suggested that its an implemntation question and not a design.

My plea is- if I change something and you do not need to know what or why I changed- it's implementation decision.

However ,if I change something- which changes how you use my services- its a design decision.

If I change my implementation to asynch from synch- I guess it is going to affect how the services are consumed- hence- its a design decision and not implementation

e.g Whether I choose XML for storage or Database- as long as it doesn't affect the other application- it remains an implementation choice rather than design

Do you agree? disagree? thoughts ?

+2  A: 

Design phase comes before the implementation phase (at the front-end of the project). Of course, you can change the design once you have started implementation if there is a good reason: this is why there an "iterative process"

product requirements -> design -> implementation -> back to product etc.

in order to converge to a product.

The Design phase exists to optimize (read: $) the implementation phase and make sure that the business objectives are met.

An architecture is yet another term that is often associated with design: during the design phase, an architecture is chosen.

jldupont
I think its incorrect to view design and implementation as two distinct phases- they really go hand in handSee comment by Simon
RN
@RN: just leave me time to finish my contribution!! When I write an answer, I very often save my drafts (not ideal I know). I use an *iterative process* here too :-)
jldupont
RN, I think he reallizes they aren't distinct when he says "Of course, you can change the design once you have started implementation if there is a good reason". I agree that they go hand and hand, but it is true that generally design should being before implementation, which might be intermingled with protyping implementation so that you can continue with more educated design. You have to begin with at least some design to establish some direction or who will know what to implement?
AaronLS
@aaronls: thanks! I've been doing Product development for >15years now in a big organization... believe me, I grok it!
jldupont
@RN: you've been very quick with the downvote here...
jldupont
Sorry bud:) Meant no harm. Removed my vote. will read the thread again and vote accordingly. Peace.
RN
A: 

I'd argue that a design decision is what you want. It's your ultimate, untainted goal.

An implementation decision is when you have to adjust your desired design because of some technical problem.

Aaron Digulla
I don't think implementation decisions necessarily require design changes. If a design calls for detailed logs, the implementation decision might be whether to use built in Trace listeners, or use the log4net framework. I can choose to go either way on my implementation decision, and I haven't changed my design in any way. It's really about delegating authority and the granularity of design. It would be like Army Generals commanding a campaign, and the squad commanders overseeing squad tactics. They are working from the same design, just different detail levels.
AaronLS
+2  A: 

My favourite definition of architecture:

Architecture is the set of decisions that are hard to change

I think that holds for the design/implementation divide as well. If a decision is sufficiently hard then it's a design decision.

The definition of "hard" is somewhat subjective and depends on your project. I would say that the sync/async decision in your question would be difficult to change later on - so I would call it a design decision.

ctford
+2  A: 

To me, a Design Decision would be whether or not to support Async and Sync or just Sync communications in this case. The Implementation Decision would be how to implement support for the Async or Sync communications.

Adam Gritt
This is another way of saying - what I meant. I agree
RN
+5  A: 

I think you already know the answer, and to be honest it is a bit of an unnecessary semantic distinction for most practical purposes. Having said that, it's design if it impacts the end user / consumer, it's implementation if it doesn't. In your example it will have a profound effect on the design of any client consuming your services, so it is certainly design.

And there is no sequence. You cannot realistically complete design before implementation starts and slavishly following a design which has a high and unnecessary implementation cost is very dangerous. You may choose to redesign half way through implementation given what you have learnt about costs.

Simon
A: 

Retrieving results and errors from an async interface will be significantly more complex, but will have the obvious benefits particularly in terms of perceived performance and flexibility. Since you have to weigh the overall pros and cons of each approach and how they meet the requirements of your application, then I would say it's a design decision.

AaronLS