I think the first question that needs to be asked is "What is the purpose of the Computer Science Department?" Is it to turn out coders? Is it to turn out Software Engineers? It is typically part of the Science faculty, just like the Chemistry Department and the Physics Department. What does the Chemistry Department do? Does it turn out people who can mix chemicals? Does it turn out people who can design chemical plants? And what does the Physics Department do? Does it turn out people who can do physics experiments? Does it turn out people who can design elevators and jetliners? The Science Faculty is supposed to teach people how to think and to use the scientific method to explore the world/universe around us. They are not responsible or equipped to turn out Engineers, be it Mechanical, Electrical, Civil, Chemical or Software Engineers. Case in point. An Engineering Professor was teaching a Software Engineering Course and was hauled before the university disciplinary committee for teaching research material to undergrads. The evidence of his crime was a state transition diagram. The typical Science Faculty is not equipped to turn out Software Engineers any more than it is equipped to turn out Engineers to build nuclear reactors. This situation has been slowly changing but obviously not fast enough. In my 25 years in the software business, I have only found 2 software developers who knew the engineering definition of the word "Design". Roughly half of all people employed as software developers have any formal training in Software Development (and I am including a Computer Science Degree). 90 percent of all software developers (and their management) have no idea what configuration management is or what its purpose is. Most think that a developer managed tool is CM. Most developers (and their management) believe that inspections are less efficient than testing at finding defects. Most software development organizations use a development process that includes frequent merges (well it works so well when developing jet planes and skyscrapers). Something has to change and it needs to change soon. We see evidence every day that our most secure software systems have more holes than a Swiss Cheese. The vast majority of software development organizations do not use metrics, even if they collect them. Even brick layers are more sophisticated that software development shops when it come to metrics.

With respect to the Hoare quote: If you build a system out of perfect parts, you are not guaranteed a perfect system but there is hope. If you build your system out of defective parts, you are guaranteed a defective system and there is no hope. Tom Walton.

At one time, just after the Wright Brothers became well known, there were dozens of companies that went into the aircraft business. Hundreds actually. But as the requirements for larger planes and greater reliability grew, the number of companies that produced aircraft shrank. Ryan Aircraft built the Spirit of St. Louis but they are not around any more. The DC-3 was the most successful airliner ever but Douglas is no longer a company on its own. Ford used to build airplanes. North American built the T-6 Texan trainer, the P-51 Mustang fighter, the B-25 Mitchell bomber, the F-86 Sabre jet fighter, and the X-15 rocket plane, as well as Apollo Command and Service Module, the second stage of the Saturn V rocket, the Space Shuttle orbiter and the B-1 Lancer. Now they are part of Boeing. The barrier to entry into the aircraft manufacturing business has gotten higher and higher as the technology advanced, margins deminished and the chance of making a living building airplanes has gone to close to zero for the individual. The same thing happened to automobiles. No more Dussenburges, Stutz, Packards, or Ramblers. Most people have never heard of a Rio. Every field of human endevour goes through the same cycle. Local farmers in my area can no longer sell to the local supermarkets. That is the domain of the big suppliers. Farming isn't new but it there is a trend towards consolidation and thinner margins that are pushing out the individual producer. The same thing is happening in Software. When the PC came out, the environment was simple and the tools were afordable. Now the tools are complex and the user interface requirements and the environment make building applications far more complicated and costly. Security is far more important now than when communication was with an accoustic coupler at 1200 Baud. Thats just life.:rose: It is possible to build a faulty system with perfect parts but it isn't possible to build a perfect system with defective parts.

This is going to date me rather severly, but I have always thought that FORTRAN looked better than other languages. To me, C (and similar languages) looks like a dogs breakfast. The next most attractive language, to me at least, is Pascal or its decendents like Ada or Delphi. You can't build perfect systems out of defective parts. But you can keep the testers busy.

AHAAAAAAAAAAAAAAAAAAAAARRRRRRGGGGGGGGGGGG! Lack of testing is the root cause of defective code!!!!! I'm sorry, but I think I may have fallen down the wrong rabbit hole. To: Gabriel.P.G People make mistakes. In software development we call these defects. A lot of people believe that the rate of defect introduction is a function of experience but studies have shown that if there is a relationship between experience and defects, it is so much smaller than the person to person variation that it is not significant. If the code produced by your organization starts out with a lot of defects, start looking at who puts them into the work products in the first place (work products include requirements, designs, code and test cases). Then worry about verification. Code has to be tested. No argument there. But code reviews are the best way to find defects. Inspections are better than informal reviews. The formal definition of an inspection is, "the visual comparison of a work product to its parent specification or applicable standard." A proper inspection process will find a larger fraction of the defects present than testing can and it will cost less. The cost aspect is something that your management should be worried about even if they are not totally mature. You can't build a perfect system out of defective parts. So it is very important to focus on the components that are built before they are integrated. Inspection followed by unit test coupled with a reasonable acceptance criteria will get the majority of the defects before integration. Testing during the integration process will find a reasonable fraction of those remaining. Once the system is integrated, testing can only be used to confirm that the developers did a good job. Nobody has the resources to test a significant sized system enought to find a significant fraction of the remaining defects. If the system is buggy at that point, you have to go back to inspections and unit testing (and perhaps redesign). If you try things like test driven development, be careful to make sure that the change actually improves things.

I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out." This is rule by committee (aka mob). Do these people also come and go any time and any day they feel like it or are there core hours for people to be at work? If there are core hours, who set them? The answer is Management. You know: the guys that run the company. Obviously a standard should not be rammed down the throats of the workers but if all else fails, then management has to say, "This is our new coding standard. Follow it." The establishment of a standard doesn't mean it will be followed. That has be be done through the code review process which I assume is part of you development process. Reviewers should not accept code that does not conform to the standard. Peer pressure is a good tool for standards compliance. A coding standard is not a static thing. So start with a standard that doesn't cause too much backlash and then grow it. Basic hygiene issues make a good starting point. If you are using C++, rules against using some of the more dangerous C compatability features are candidates. Basic formatting and naming conventions are candidates. Things that cause problems are candidates for a new entry in the standard. There are lots of coding standards on the Internet so pick one you like, modify it to suit your situation and propose it to management. If that doesn't work, then sedition may. In every organization there is a developer that is looked up to by nearly everyone. Recruit him/her. If he/she starts to use the standard that you produced (with perhaps a few changes) in his/her own work and as a guide for code reviews then its use is likely to spread. Again, peer pressure is a good tool to promote compliance. The first objective of a coding standard is to make all the code look like it came from the same company. The second is to make it easier to read and modify. You can't build a perfect system out of defective parts. But you can keep the testers busy.

I see testing there on the second last line. You must be QA