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 383381
To read all comments associated with this story, please click here.
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