Am I the only one who reads davidsporn''s name as "David''s porn"?

quote:Original post by Xeee
which is more important/harder, Design or Implementation?

Generally speaking, neither. It''s an arbitrary distinction.

quote:Original post by SabreMan
Generally speaking, neither. It''s an arbitrary distinction.

The line between design and implementation is arbitrary? I see the difference as creation vs. translation. An great example would be speaking in a second language. First you think of what you want to say in your first language, then you translate it to the language in which you are speaking. Sometimes, due to technicalities of the language, it is not a direct translation, so you must improvise, or change the basic layout of your sentence. Which seems to closely mirror design and implementation.

As to which is harder or more important, I agree with SabreMan, neither is more important. Implementation is obviously a much larger part of the end result. Meaning, that the point of design is to write good code, and if you implement it well without a good design doc, all''s well that ends well. And if you implement it with a good design doc, the coding should go faster. And in that way I can see SabreMan''s point about an arbitrary distinction, as both are a path to a goal.

it depends on the method you use

if you use refactoring as a principle then the structure of your code will be maleable. you can transform your bad design into a good (or even great) design in incremental stages. testing is the key to managing the fear people have of vastly changing their code. the things you are aiming for by refactoring will start to permeate the new code you write as well.

requirements and design are two different things. if you don't know what you're trying to produce then you're bound to have to change your design as the purpose of the software becomes clear.

i've never worked on a project where the requirements were fully specified and it's probably the biggest cause of stress in my life. refactoring as a method makes it easier for me to cope with the changes that invariably follow.

refactoring and xp encourage code ownership policies to be weakened within a company. the only places of concern are published contracts, i.e. file specifications, network data format, library APIs etc. the stuff that goes on in the background can be as fast and loose as you like. the testing gives you the confidence to change.

[edited by - petewood on December 30, 2002 5:05:42 AM]

quote:Original post by Neosmyle
The line between design and implementation is arbitrary?

Very much so. If we were to ask each person here to define the terms "design" and "implementation" we''d probably end up with lots of varied definitions, indicating that the meaning is arbitrary. But we don''t need to do that. Try considering different development methodologies. Waterfall, DSDM and XP provide good distinctions. Each of those places a different emphasis on the roles of design and implementation and the division between them. In XP, coding *is* designing, and there''s a lot more sense in that than your gut reaction might suggest. So, the OP''s question cannot be answered without a definition, and even if it can be answered, the answer is unlikely to be useful.

quote:
I see the difference as creation vs. translation.

That needs you to define when you are creating and when you are translating. Be careful - I claim that when you are coding, you are still designing. You *will* change the design when you are writing code.