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 383343
To read all comments associated with this story, please click here.
RE: Best Article Ever
by cpiral on Fri 11th Sep 2009 00:05 UTC in reply to "Best Article Ever"
Member since:

Congratulations. This is the best essay I've read on OS News ever. No kidding. Ever.

The problem I have with the best article ever is that it seems like it is trying to program me to think like it. It is way ahead of it's time now, which is exponentially changing. It was as much effort for me to wrap my mind around it's further implications as it was slowing my thoughts down to the speed of the following words.

"Design and Implement" is a style of getting things done. Trees get forests done, but the forest is specification for the space. The purpose for specifications is too big to see, like the planet. The specification is a style that makes more readable now for some unique individual in the forest we cannot see. One is too small to see the planet. The payload, Yamin says, is the actual thing, the facts inside. The payload of Design and Implement is getting things done while in a primitive society that is full of "cover your ass".

In support of the articles premise, why suffer the duress of such dress? Network protocols packetize and frame better. Computers encapsulate better. When we build a computer better at human language than a human is, we won't be so primitive any more. We will then have a basis for tailoring a common language that will do as Yamin says.

Design specifications are like manuals of style, the wordiest of manuals, and love to propagate themselves. And (it is my momentary opinion that) to the extent that we deny this our machine-like repetitive propagative nature, we will fail to materialize the happiness that comes from getting change done. It is most human to say "Silly language, words are for deeds." But humans are fallible and imperfect, and are indeed a cog in a planetary system in transformation, and out of which gracefully we move.

Human language is largely purposed for programming our motives. (We are our own worst enemy.) What motivates each of us is both our verbal and motor skills. Words are like this and are used to control through masses-media programming. So you see, now, the practical perspective of specifications? I hope not.

Granted wholeheartedly many words are an inhumane affliction, like too much physical labor, and can "kill the spirit" of our moment by moment. Witness, for example these words as few are ever willing, and fewer ever will. That many Americans choose not to read is as natural as a cat disliking water. And we trust this because organismic behavior is in the now, while wordy programming is a language for some private future. The rub of life is such.

OK. No two humans are alike, nor can they understand in the same way, most specifications, or any book, or language. Complexity is questioned, and the questions determine the answers. So we have the "many answers" problem. There are as many answers as there are possible frames or paradigms. This is the price we pay for change from trusted old ways. Trustworthiness increases with decreasing complexity and sophistication; fears and complaints increase with increasing complexity. So we change slowly, gracefully, balancing all the way to the future.

Language is for someone's "to your specifications" for a future. Specifications are visions, and they trump language like pictures trump language. Even when we get a common language, life will have the aspect of "design specifications" in it somewhere, because we're not all visionaries. And no one can see the larger dimensions of our forms. What the article has done, stunningly well, is highlight an important aspect of a life, seen from Yamin's private position, that we cannot wholly understand.

The future is being built by specifications from project builders. The planet is a "project I'll" (projectile) in space, projected from private positions. It is far too human and thus a project of protracted proportions. I love words, but they bully pound to a pulpit. There should be a new regulation on them...

It was the best of articles; it was the worst of articles, it was an article of the times. Good programming OSnews.

P.S. Thought developed language. There is thought without language. But there is no language without thought. Similarly I predict that the "thought" that will develop a practical, common language will come from fruits of the the natural language processing field in computing.

Reply Parent Score: 1