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?
Permalink for comment 383154
To read all comments associated with this story, please click here.
Some things from the article
by mightshade on Thu 10th Sep 2009 00:43 UTC
Member since:

Let me first say, I agree with saynte and Bill - a short introduction or final conclusion wouldn't have hurt. As far as I understood the article, there are two basic statements:
1. The waterfall model and similar ones suck
2. There is no implementation, everything is design
Congratulations for inflating that into three full pages. ;) Now seriously, please be more concise next time.

Anyway, I'll pick some things from the article and comment on them.

I agree that the traditional waterfall model isn't terribly efficient. From my own experiences, I concur that for any non-trivial project, it's almost impossible to completely lay out the design at the beginning of the development process. OTOH, the idea that you should or even have to specify the software entirely beforehand is a misconception as well.
You can, technically, design every bit of the architecture and the algorithms with class, activity and other diagrams. However, when you're actually down at that level of detail, there is no need for an intermediate language anymore. Diagrams that precise could be compiled directly. But you're not doing that. Like noirpool said, design is about abstraction. Being independent from the programming language, and having a guide to "what" should happen, without exactly detailing "how" it should happen.

Programming languages have gotten so good and have gotten rid of so much of the fluff that they essentially have become a very good way to represent algorithms.

Agreed - but they're still relatively bad at describing the system at large, including several packages, classes and their relationships. Which gets almost trivial when using a more abstract modeling languages, like UML. The book "Software Engineering for Game Developers" has an example on that in chapter three.

Source code is a valid specification on its own.

I'd say: Yes, but the specification isn't complete without the addition of the more abstract design. I, personally, would never accept code as the only specification. That's because, as I wrote, even today's languages aren't doing a good job at conveying the "bigger picture" to me, the reader.
Well, that's obviously just my opinion, which stems from my experiences at different forums. Most of the time, someone asks for help with his program, leaves a very generic statement about what's wrong, and then posts a page of source code. While this code may be regarded as the "specification" of his program, having no abstract explanation at all makes it unnecessarily difficult to understand the "what (should happen)" of the program.

100% of software is design from the high level architect-like design to the low-level design of a for-loop.

That is just semantic hairsplitting. So when I e.g. take my class diagram and write Java code according to it, it's perfectly reasonable to say that I'm implementing. You could say I'm implementing (static parts of) the classes, while designing the algorithms, but... splitting hairs. Seriously.

Many of the terms (...) may seem reasonable from an abstract academic point of view

You might be right that the idea of engineering software without writing a single line of code comes from the academic world. Being able to make statements and predictions about the to-be engineered software before actually implementing it is very popular here at my university.

Reply Score: 1