A good design should be considered like a good road map, enough detail to ensure you head the right direction – but not so much detail as roads are obscured by all the other details along side – which can be left for the journey to fill in. Unfortunately from what I have seen, it is an area Agile seems to forget in practise and involves lots of re-factoring to bring back on track.

But then some developers seem more interested in CV++, liberally flooding the project with the latest buzz word technique whether appropriate or efficient for the project/action, than actually producing a system.

"The purpose of science is to simplify as far as possible - but no further".

We've been here before. Many times. We learnt this lesson when we programmed mainframes and had to count clock cycles and co-ordinate media reads to make things move at peak efficiency. We learnt this lesson, again, through the rise of mini/departmental computers and how we got the buggers to talk to each other. We learnt it again with PCs and the muddle of client/server. We learnt it all over again with the web. We will be learning this lesson as long as we need to develop code because every time time we learn this lesson we forget it. Why? I don't know, but I'm getting bored watching happen again and again and again.

Complexity doesn't start at what you do. It already starts at what you choose to use.

If you are using programming enviroment X ask yourself, if you really understand it. Could you implement a basic version of that enviroment offering you every feature you need while beeing able to be extended to the other features?

The point is, if you don't know your enviroment down to a basic level, you will not be able to understand the many side-effects of your work. Those enviroments, especially C and C++, don't properly hide the many shortcuts they take. You will need to know what the enviroment is doing with your code. Otherwise you will miss a lot of bugs.

In my opinion it's not a good thing, if the reference book of the programming language you are using could cause head traumas.

What exactly is the point of this article?

Incidentally, simple designs do not neccessarily = simple to maintain. A simple design could be argued to be with the least amount of abstraction, the least layers etc. However, as soon as you add new features, make changes you start to get all sorts of problems with lack of proper isolation, no injection etc. Therefore simple design should mean clean, consistant design that it actually difficult to break.

I'm also a little confused by the don't try to test designs - surely the design should actually be the test in this day and age? Or is that too complicated?

"...it is not possible to test a design to check its completeness, its suitability or to validate its functionality."

This is not true. There are many tools that can model-check important properties of a design, such as concurrent behaviour, resource usage, etc.

If you choose a modelling notation that has no formal semantics, then you can't prove anything about the system from the model. But that is the point of modelling, so why even bother. If you can't actually use your model for modelling, you're wasting time drawing (not so) pretty pictures or writing gobbledigook in some worthless notation when you should be delivering software.

Methinks we have another pointy-haired type here who sees a nice solid wall between "design" and "implementation" with code on the latter.

*sigh*

Why do I always have to work with these amateurs?

We use Rhapsody where I work. Essentially, you keep annotating UML and adding code snippets until code = design. Complete piece of crap and utterly the wrong way to solve the problem of making the software match the logical design (and vice versa). There's a little thing inbetween called "physical design" which these tools kindly step over and make my life a bitch. Logical design != physical design.

Methinks I hear a cry of "clues for the clueless!"

Code NEVER equals design, not in any way, shape, or form! I have never seen any implementation that is so bleedingly obvious that the design just leaps out. If the code is that simple, then it was a trivial problem. I have spent many hours working with code that was never designed, and had no or piss-poor documentation. The difference between spaghetti-code and a purposeful design is immense.

A design (and its resulting documentation) makes the data obvious, what actions can be done to the data, and what actions will constitute the complete program. Read a book on Warnier-Orr design, or the Jackson methodology. Seriously! I have solved the "impossible" using design techniques.

Designs are tested by verification. That means that somebody else takes a look over it. After that the design is implemented, and the implementation is tested. If there are errors, then you go back and look at both the design and the implementation.

No, there isn't a big solid wall between design and coding. But if you don't know how to design well, your code is going to be crap. A design document is both for you and other people. It is an abstraction of the idea that is implemented in the code. "Just read the code" is an arrogant statement, and is usually uttered by posturing amateurs.

It is amazing just how often coders take trivial problems and turn them into spaghetti-monster

...called KIS

They just "Keep It Stupid"

I seem to remember you and I posting on this Code <> Design issue before on this same site. Yes, Code != Design, and Design > Code.

Simplicity starts with design? What is simplicity? Can someone give a definition please? Is it a requirement? Is it a specification? Is it a platitude? Is it a constraint on the design?

Sarah Skelding - So what you are saying is we (software developers?) have not really learnt the lessons or passed the lessons learnt on.

Anonymous Coward - "A good design should be considered like a good road map, enough detail to ensure you head the right direction". Yeah, if you have the ability to read a road map. People who say driving == the road map are the ones who do not have the skill or experience of reading maps let alone creating a map. We all end up getting lost and running out of fuel and then doing the death march pushing the bloody bus up a hill.

Hypothetically (of course), if a "design" document says one thing and the code says another. What is the actual design of the resulting software, hmmm?

This does not mean that ancillary design documentation is not useful, nor that one should only have the code as the sole representation of ideas. There are other ways of representing and working with concepts beyond mere code, but they are there to help the design (the code), not separate design from code which cannot be done.

There are some famous essays on this, "Code as Design" by Jack W. Reeves. If you haven't read them yet I recommend them.