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?
Thread beginning with comment 383669
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Great article!
by TemporalBeing on Sat 12th Sep 2009 11:28 UTC in reply to "Great article!"
TemporalBeing
Member since:
2007-08-22

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:
2006-01-10

"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

RE[3]: Great article!
by TemporalBeing on Sat 12th Sep 2009 22:29 in reply to "RE[2]: Great article!"
TemporalBeing Member since:
2007-08-22

"But then why write a specification"

Because it helps you write source code.


That is exactly the wrong answer.

Specifications are closer to contracts.
They clarify exactly what is to be delivered so both sides (customer and developer) are clear and understand the final product.
But they do NOT provide the implemenation. If they could, the customer would not have needed the developer to write it for them - they would have already done it themselves.
BTW, specifications are then used at delivery for the customer to verify that what is being delivered is what was agreed to; and payment can be withheld if the two don't match.

You can transplant this to any field.


Not quite true. It applies specifically and most literally to any engineering field, but only abstractly to any artistic field, such as the literary field you mentioned.

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.


That is the design of the book, yes. However, some authors do in fact just sit down and write; and produce great works - though they are few and far between.
Others put in lots of research before hand, then sit down and piece it all together, for example Gaston Leroux put in tremendous research before writing L' Fantom de l'Opera, e.g. The Phantom of the Opera.

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.


Funny you mention Shakespeare - he likely didn't do any of that, and yet his works are considered some of the best. Same with Homer, and likely Plato too.

That said, writing classes often involve the entire class being given the same outline, characters, etc. and each student then having to produce their own work.
But as I said, this really only applies abstractly to the literary field.

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.


Quite true, but they would all follow the same literary formula - they would all meet the same specifications. This kind of thing is done quite regularly by authors.
One reads another's books, puts together similar plot, changes the names, the backgrounds, and writes their own book. Such things are known as 'literary formulas' and are typically used to mass produce books. For example, this technique is often employed by Star Trek, Star Wars, the writers behind Nancy Drew and The Hardy Boys, and more. It is often applied to films as well.

Only the final writeup is important.


Important how? Important in how it actually functions or looks? Yes. Important in that it matches the specifications? Yes. Important in that it can't be replaced by something else that meets the same specifications? No - and that is where your proposal fails.


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.


It is implementation for several reason:

(i) It details with certain details - e.g. implementation details - that are below the design. For example, whether to use a '=' or ':=' as the assignment operator, what to name the functions, the variables, etc.
(ii) It is one implementation of many possible implementations that meet the specification, design is part of the specification not the implementation.

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.


I talk to people outside of software quite regularly. And none, have I found, find software to be a menial task - most are petrified at the thought of trying to do it themselves.

No, the people that think implementation is a trivial task are the programmers become managers, those who have stopped programming, and those who got their degree in the aboration that is Information Systems. They can write a script to add 1 and 1 to get two, and they immediately think the world of themselves.

No, most people realize there is much more to software development than meets the eye. They know there is a lot of work that goes into it, and they don't understand it. They likely never will; and they respect people who do it because they think there is a witchery behind it.

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'.


Your 'outside' world is vastly limited to the IS people - the people that failed out of the CS or CE programs and chose to do something similar out of pride. Thus they studied at how to being a traditional software engineer, and try to be managers instead, they got their MBA and can only order people around. They think they know what they do not, and will never let you know otherwise no matter how foolish they are.

I've had a number of managers. The good ones were rarely software people at all; and they realized they did not know something and turned to the technical people who did for support and help. The bad ones, on the other hand, thought they knew the world and would not have it either way.

Yes, Software Coding is Implementation, and it cannot be anything else. And, by the way, low-level design is another practice all together so calling implementation design is not right either.

I am no advocate of Traditional Software Engineer (see the other related threads for discussion on that), however, it would greatly behoove you to learn something about it.
But, to keep it shorty, if one were to follow all of Traditional Software Engineering then it would go like this:

Concept Of Operations
Architecture & Requirements
Design
(Optional) Low-Level Design
Implementation Specification
Implementation
Repeat until satisfied.

Reply Parent Score: 2