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 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
mightshade
Member since:
2008-11-20

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

Slambert666 Member since:
2008-10-30

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.

In my day job I often work with projects that has "blown up" and the three most common project methodologies that blows are Waterfall, RUP and Cowboy.

The Waterfall'ers almost always blame lack of time.

The Cowboy coders has left the project... :-)

The RUP'ers are by far the most annoying of the lot, usually blaming the users for giving bogus specs, lack of people, money etc. Unfortunately they never blame RUP and their useless diagrams, and the fact that they spend the last couple of years on nothing (rather than producing something of value).

The managerial problem with RUP and related tools is that they give the illusion of progress in a project where it does dot exist.

Listen to this and learn before it is too late:

"Diagramming exists to assist coding NOT the other way around."

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.


When you say "languages" I assume you mean English? :-)

You can generate UML diagrams from code written in many languages if you want to, but if a drawing conveys more meaning to you than code, you probably should not be programming in the first place (has something to do with how the brain works).

Reply Parent Score: 1

mightshade Member since:
2008-11-20

That are interesting insights, and I can only agree with your conclusion: "Diagramming exists to assist coding NOT the other way around".


When you say "languages" I assume you mean English? :-)

No, I referred to programming languages. However, now that you mention it, the same is also true for natural languages in my opinion.


but if a drawing conveys more meaning to you than code

Well, that's not what I wanted to say. Diagrams don't convey more information - they convey less, because of their abstract nature. Their strength is their higher efficiency in conveying the information they contain.

Take a class diagram as example. You can see the classes and interfaces, their inheritance relationships, and any other way how they relate to each other. What you can't see is how the classes' operations are actually implemented. But at this point, that doesn't matter. What matters is that alternatively, for just understanding how the classes collaborate, you'd have to hunt through all of their source files.

Reply Parent Score: 1