Linked by Yamin on Wed 9th Sep 2009 16:17 UTC
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 383102
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-01-10
I'm not against top down or documentation. I kind of anticipated some people taking the article that way. I thought I'd prempt a lot of it with the statement at the beginning of the article as well as in the conclusion.
"Top-down works ... requirements to functional specs to programming specs to code"
I'm not disagreeing with that. I would 100% agree with requirement and functional specs.
It's the programming specs where I tend to have the biggest issue. There are useful design documents and programing specs. This is especially true at the high level. But in no way you can discern the full functionality and behavior of a program from the design document.
My point is that to fully specify a program... is to code it.
For example, let us say you are building a router and some weird condition happens that causes a problem. Some packet comes in with a specific bit set while the router is receiving a BGP update at the same time a new route is being written to the route table.
Is how you handle this going to be in the programming spec? I doubt it, otherwise you end up with a 100 000 page spec.
Your spec will end up look exactly like code, except written in English with overly verbose if statements lacking the clarity of a regular programming language. In the end, your support staff is still calling the programmer and asking them what happens if this happens or debug some issue.