Linked by Yamin on Wed 9th Sep 2009 16:17 UTC
General Development I've been developing software for quite a few years. One of the issues that seems to come up again and again in my work is this concept of design and implementation. I recall it being a significant part of my education at the University of Waterloo's Computer Engineering program as well. The message was always the same. Never write code first. First you must design software by writing a design document, flow charts, pseudo-code, timing charts... then it's merely a trivial matter of implementing it. Make note of the attitude here given towards implementing. The real work is in the design, and it's just a trivial matter of implementing it. It sounds so simple doesn't it? Now, how often does this work out in real life?
E-mail Print r 8   · Read More · 82 Comment(s)
Thread beginning with comment 383666
To read all comments associated with this story, please click here.
Great article!
by RandomGuy on Sat 12th Sep 2009 11:00 UTC
Member since:

The basic point that a sufficiently detailed spec actually *is* a program cannot be stressed enough.

Reply Score: 2

RE: Great article!
by TemporalBeing on Sat 12th Sep 2009 11:28 in reply to "Great article!"
TemporalBeing Member since:

But then why write a specification?

The problem is thus - where to draw the line between lack of specification and over specification.

If you do not specify enough, things go awry because there is not enough clarity.

But if you over specify, then you leave no room for error in the design and flexibility in resolving problems - you essentially micromanage, and write the code yourself.

There is a balance that must be found between the two, but that balance can only be properly struck once there is a true discipline to the software field, and coders lose their arrogance. Sadly, it will probably be a long time till that happens.

Reply Parent Score: 2

RE[2]: Great article!
by Yamin on Sat 12th Sep 2009 20:26 in reply to "RE: Great article!"
Yamin Member since:

"But then why write a specification"

Because it helps you write source code.

You can transplant this to any field.

Suppose you are writing a book.
You don't just start writing. No, you probably think of a plot first. Create descriptions of characters, their backgrounds. You even think of the killer ending.

Those all sketch out the general specification of the book. Yet, you can't take those, hand them to anyone and think they would produce a work of literature as great as Shakespeare.

No, the actual writing of the book is very important. Give the general specification to anyone and you would still end up with a million different stories.

Only the final writeup is important. Now I would think of all writing as 100% design. If you think of this writing as 'implementation' then I think we're just too far off on the meaning of these words.

As it is with source. You should never start writing immediately. You must gather requirement, do high level design... but at the end, you MUST produce the final design... which is source code. It is what specifies everything in absolute detail and clarity.

If you don't think implementation is just dummy work. I seriously suggest talking to people outside software. That is the mentality. That someone can write a spec or a design document and then then it's just dummy work to implement it. It is not their fault they think this way.

Even if you still disagree and think of software as implementation... I would still suggest just changing the wording you use to low-level design for the good of all people in software. Take it for the team. Otherwise, in the minds of those outside software, software will still be views as being designed by 'architects' and 'analysts', while being implemented by anyone who knows 'C#' or 'Java'.

Reply Parent Score: 2