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?
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-02-26
Architecture & Requirements
Design
(Optional) Low-Level Design
Implementation Specification
Implementation
Repeat until satisfied.
Just for reference if anyone does decide to look it up, this is traditionally known as the Waterfall model and is generally accepted as bad practice these days, even among software engineering proponents.
Member since:2007-08-22
Actually, no - the Waterfall Model is one method of how you work with the various parts. The other models (e.g Spiral, Incremental, Evolutionary, etc.) all use those same parts but incorporate them differently.
The Waterfall Model, for example, only does each of those once. One time, period. No 'repeat'. You're done after the first iteration.
The Spiral Model, puts the Waterfall Model into an iterative loop, but only for a certain number of times.
The Incremental Model cuts down the amount of work done at any given iteration and tries to build on itself so that in the end the product will be the same as the Spiral Modal.
The Evolutionary Model is more like the Spiral Model with an infinite loop, but typically cut down for any given iteration like the Incremental Model.
Needless to say, ALL current Software Engineering Models require the steps in my previous post. It's just how you iterate them and the amount of detail at any given iteration that makes the difference.
But yet, the Waterfall Model is generally considered bad practice - namely because it is not iterative in nature.
Member since:
2007-08-22
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.
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.
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.
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.
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.
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.
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.
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.
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.