OSNews

<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.