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?
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-01-10
"The source code of software IS the implementation of a design - that is its nature, since you can implement the design of a program in numerous languages and still have the same program operating the same way - whether you implement it in Java, C, C++, Objective C, Assembly, or YAL (Yet Another Language - whatever you please)."
Yes, I guess we do disagree here.
I'd view a design as the final plan of a product. The final design that you can hand to some implementer who can go and follow your instructions to get some final output.
I don't really understand the relevance that you can express source code in multiple languages as somehow making it implementation.
Almost every design can be expressed in different ways.
Source code is just one way to express the design.
It's a really good way. But suppose I wrote a compiler that instead of taking in source code, it took in flow charts (visio) and compiled that and produced code. Would that make flow charts not design?
If a mechanical engineer designs something like this:
----------
Cut a rectangular piece of plywood 5 foot by 6 foot and 1 inch think.
Or he gives a standard autocad blue print of it.
----------
Both convey the same meaning. Both are design. One is more standard and more precise than the other (autocad). The language of design really doesn't matter. It is merely like all languages, the expression of the design.
Or suppose I want to write a book (refer the final quote on can you have thought without language). I have all the content in my head. I just need to express it so others can understand it. I could choose to express it in English, French, German... At some point, for me to convey my thoughts, I will just have to pick one of the many languages suitable to express my thoughts and do it. Then if you wish, it can be translated into other languages.
The fact that you have choice in how to express the design is not a problem. I could for all purposes express my thoughts in a painting. It would be very vague and I'd probably be asked a million clarifications as to what is meant by it, but I could.
Similarly, source code is merely an expression of design. A very low-level, precise, and detailed one and one that can be understood well by out compiler implementers. If we could design a compiler to hook up directly to my brain or understand english... then we wouldn't need source code.
Anyways... still got some work to do to convince people that all the implementation is software is done in the compiler. All the rest is design. Source code is design.
Edited 2009-09-12 15:39 UTC
Member since:2007-08-22
And that, my friend, is as you so eloquently described without realizing it why source code is implementation.
The problem with source code is that it only states what actually happens, it does not carry intent. And that is the difference between design and implementation.
Design carries the intent of what is desired; implementation makes that intent a reality by trying to match what is desired as closely as possible.
Different programming languages have different sets of limitations - for instance, C vs. Java vs. Assembly vs. HTML. Some of those languages would be utterly prohibitive for many programs (e.g. HTML). Likewise, implementations can be tweaked to provide certain characteristics that designs cannot - e.g. having a mixed language program, calling out to assembly from C, C++, etc.
By contrast, English vs. Greek vs. Chinese have no limitations in themselves other than what culture puts behind it. What can be said in English can be nearly as expressly said in Greek or Chinese if one is fluent in the others, but not so by someone who is not perfectly fluent in both the original and translated versions.
But again, I'll appeal to the post of which I am replying for an excellent view of why source code IS implementation and NOT completely design.
Member since:
2007-08-22
<quote>However, the final design is software code. That is what the compiler reads and finally outputs. </quote>
And here is where we - and I say we as others in reply have expressed the same - disagree, and you would by logic have to disagree if you really agree in full (as you state) with what I wrote - because I explicitly wrote the opposite, as have others.
The source code of software IS the implementation of a design - that is its nature, since you can implement the design of a program in numerous languages and still have the same program operating the same way - whether you implement it in Java, C, C++, Objective C, Assembly, or YAL (Yet Another Language - whatever you please).
While your teachers proceeded under the false assumption that the implementation is trivial - most don't. Indeed, good teachers would not as they themselves realize that as with Civil Engineering the implementation is no more trivial than the design itself. Indeed, with Civil Engineering you have many people working on the implementation and many checks to verify that they are all following the design to the letter, and even more so - following the standard procedures that are not part of the design but assumed by the design - assumed by the Civil Engineers that wrote the design.
Conversely, in software there are extremely few standard procedures that anyone that only performs design can assume - thus the design must be clear all the way down to the source level, and sometimes further than that - explicitly stating what the machine should do at the machine level. (Indeed, some systems require such accuracy.)
However, as stated by myself and others, source code only tells you what the software actually DOES, not what it was INTENDED to do.
Perhaps you need to think a little differently -
Source Code is the implementation of the final software specifications - that is how Traditional Software Engineering sees the source code, however wrong it may be (and I do agree that view is wrong).
The primary problem at all levels in software engineering is that the field has yet to formulate standards, and software developers are to arrogant to follow what has been laid out - they want to do their own thing regardless of what anyone tells them. So there is a great lack of discipline in the field.
Conversely, when a bridge builder is helping to build a bridge there are only certain ways in which the builder is allowed to put a rivet in, certain methods of how a weld is allowed to be done, etc. And for instance, many of these are verified by others - a welder does not simply weld and go away; rather the weld is inspected and verified that it is to specification required by law and by the design (since the design usually exceeds the law). The inspection may primarily be done my a master welder, but the welder is ultimately responsible for any failure in his work - if the weld fails and someone dies, the welder and (even more so) the weld inspector may be charged with criminal negligence, and the company that built the bridge would be in court for wrongful death. There is liability attached.
Now consider software implementors, and designers. Are any of them liable for failure to do their every day job? Aside from being fired, there are few that are - namely those that are involved in fields of life and death, but even then it is likely rare the software coder would be liable beyond being fired.
Does anyone inspect the code to verify it against a design? Does anyone verify that it properly handles failures? Do most programmers implement not just units tests but also functional tests? Are most programs even testable to be verifiable?
Sadly, the answers are mostly a resounding 'NO'; and most of this comes back to a lack of even basic discipline in the software field, and the arrogance of software coders such that they refuse to do anything in any way other than their own - especially when it comes to coding styles.
So while you call out for documentation, you primarily fling it back in your analysis as something that is not required since the code should be documentation enough - and that is not the case. If that is not what you meant, then you failed at such communication - both in your original set of articles and in your reply to my original post.
Traditional Software Engineering has many faults; faults which need to be corrected. But the culture in which software is produced also has many faults that need to be corrected. And software will continue to flounder about as it has until these are both resolved.
But there is one other thing to remember - they must be resolved such that they are practical for software coders and the companies that employ them, and this is a great part of the failure of Traditional Software Engineering, which is also partly (but not wholly) attributable to the arrogance of the software coders as well.
Sadly, I think while you hit on the nail of one side of the problem, you also fail to realize the whole of it, or even the entirety of what you wrote.
And with all respect, I sincerely ask that you sit back and think a lot more before writing on the subject again - think about the implications. I would also be willing to work with you more on it, and if you so desire then send me a message privately and we shall go from there.