Replies

The idea is that it's best to find problems early

It's better not to build problems into product for anyone to find. It's the whole concept of TQM.

That statistic of 1 in 4 lines of code having an initial bug is ridiculous. We didn't have that experience when software was built with no architectural, engineering or design phases. Just sit down at the keypunch and start coding.

I have trained over 4,000 professionals in both structured and object oriented design disciplines. The most common observation of my peer students was that they recognized that solid architecture, rigorous engineering and design principlesand processes produce superior product but their managers wouldn't let them employ discipline and rigor. They, almost to a person, claimed their managers would tell them, "I don't care about that stuff. Just get it to work."

If you want to look for the source of problems in software, look at Human Resources. There are very few organizations that have a career path for professional software developers. At some point, the organization, in order to reward a good employee, will take a perfectly good technician and make him or her a manager.

That's the biggest problem in software production. After X years, many of the best developers become the worst managers.

Remember Watson-Watt's "Cult of third best"

The "best" system can never be implemented in practice.

The second best takes too long and costs too much.

(Watson-Watt was in charge of developing the British Chain-Home radar system, which arrived just in the nick of time.)