OSNews

There are several problems with the proposed approach, and I won't re-iterate the details of what has already been said - just summarize and add:

1. Code may be incomplete too; it only tells what actually DOES happen, not what it was INTENDED to do. You can no more read the mind of the coder than you can the specification (design, architecture, concept of operations, requirements, etc.) writer.

2. Specifications are NEVER complete. You can't necessarily capture all use cases in the specification. One implementation language may have use-cases another doesn't, and the specifications writer may not understand the language specific implementation details.

You also start with the assumption that THEORY makes the program. Suffice it to say, it doesn't; and the Academic world is killing the prospects of the students for it. Academia focuses way too much on theory, and no where near enough on the practical implementation. Businesses care more that a programmer can (i) understand the concepts presented, and (ii) implement that concept than they do that the programmer can theorize about the concept and vaguely tell someone else how to implement it. They are in business to MAKE money, not pay multiple people to do what one person could have.

However, that still doesn't get down to the root of the problem you are trying to solve. The biggest problem in programming, aside from Academia - though Academia is also partly to blame for it, is not so much theory and implementation, nor how programmers are taught to program, but rather the lack of discipline in the field and the arrogance of programmers themselves.

To start with, a lot of programmers write software as if they are ever the only person who will ever, ever touch the source code for that software. But that is absolutely wrong - most programs are initially setup by either one person or a small team, and then quickly replaced by others who then have to maintain it. Whether they initial writer leaves the company and goes somewhere else, or simply moves onto another project - it doesn't matter; someone ELSE has to pick up the ball and carry it. And sadly, that someone else does the same thing.

Additionally, as programmers we more often than not fail to get even half of the user's requirements before we make assumptions on how the program should operate. And then not only are our managers surprised when the user doesn't like (or even use) the software, the programmers are too!

Needless to say, I think most all of the problems in software can be brought down to a matter of the lack of discipline in software writing, and the lack of humility of the programmers to follow even basic coding styles as a team.

Discipline must be followed in every step of the way - from gathering thorough requirements (as much as the user can give, not as much as it takes for the coder to decide what to do), to handling error conditions at every possible point (it's far more robust, and C++/Java Exceptions lend no help to this matter; that's not to say they are not a useful way of communicating errors, but those errors must still be handled at every possible level in the program, not simply caught and discarded, or left to a higher level to find), to design of interface (both HCI and CCI), to documentation IN the code, and specifications writing (at all levels - concept of operations, requirements, design, etc.) There's more, and hopefully I'll someday be able to publish my full thoughts on the subject to OS News and Slashdot, but it won't be today. (I'm partially still gathering my thoughts together to write, and also need to write what I already have more thoroughly; but it will happen in time.)

It's obvious from the article that the writer missed the point of design; but they probably also missed (likely entirely) the stages that PRECEDE design - concept of operations, requirements gathering, and architecture. All these stages are important, and all, as with those that follow them, are iterative. But none of them solve the end problem - stable, secure, robust software - because all fail to capture everything. These stages (design and implementation included) are what I call Traditional Software Engineering, and the only people that can afford to do so are those who are putting lives in danger (e.g. DoD, NASA, etc.) and cannot afford even the slightest error. (That said, DoD Contractors don't do it quite right either - they only do as much as the Gov't Program Manager makes them, who only does as much as the Gov't budget allows.)

There has to be a better way that makes it practical, and being more disciplined about software writing at every step of the way is at least part of it.

(Obviously, I'd love to hear other's ideas on what it means to be a disciplined software developer.)