Hi there, On Fri, 6 Nov 2009 Nathan Gibbs wrote:
> Cut these guys some slack. > They can't do everything. This isn't about cutting slack, or for that matter pointing fingers. It's about contributing. I'm contributing. Sometimes people don't want to hear what needs to be said. That can be painful all round, believe me. > Thats the beauty of Open Source. Let's just say I'm familiar with the concept and leave it at that. We don't want you to get your foot completely stuck. :) > ... report that its broken. If possible Where is it broken, why is > it borken, and how it might be fixed. That's exactly what I'm doing here. Unfortunately my message is not one which people often want to hear. They want to hear what a great job they do, not how they could improve on how they're doing things by doing things for which they really have little sympathy. There isn't some piece of code somewhere that has to be tweaked. If it were so it would be great, they'd just go off and tweak it and all would be well. But it isn't like that. The issue here is that if there is any system which is supposed to prevent problems of the sort that we see so often in releases of ClamAV, then demonstrably it isn't working. My contention is that there is no system, and that's what needs to be fixed. But as I don't employ the developers, all I can do is point to some of the benefits of using modern (i.e. developed in the past fifty years or so) quality systems. We no longer have to promise that the architect will be executed if his building falls down. But there are still people in governments talking about penalty clauses in software procurement contracts because they don't know any better. Sorry, any better way to get the systems delivered on time, under budget and with acceptable levels of faults and performance. Quality systems can and do result in improvements of a couple of orders of magnitude in fault density in software (measured for example in coding errors per 1000 lines of code). The user's experience will inevitably improve as a result - and let's not forget that one coding error can easily cost several hours of the time of each of thousands of the code's users - but in addition, the developers will be able to get on with their developing instead of spending large chunks of time tracking down the faults which they themselves put there because they didn't have some kind of system. Obviously I don't claim that all errors can be eliminated, but I have seen the results of using and failing to use quality systems and the differences can be stunning. It's no exaggeration to say that the cost savings in industry are phenomenal. I've seen manufacturing cost reduced by more than 60% and reliability improved by 500% as a result of proper quality control procedures being applied. I've also had to fly to thirty of the United States to replace four 10 cent components in a couple of hundred examples of a fifty-thousand dollar product because the quality control procedures were ignored. The cost to one company of ignoring a few simple quality procedures which would have found the problem at the sub-assembly manufacturing stage was tens of thousands of dollars in repair bills and very much more than that in loss of customer goodwill. The cost of finding and fixing the problem if the procedures had been followed would have been a few dollars. This is a natural result of the logarithmic relationship between the cost per fix and the stage in the product's life at which the fix is applied. It doesn't really matter what the product is, and despite what you're thinking right now it is _very_ relevant to software, if the software is built in anything like a modular fashion as probably it should be. Here's an example of an implementation of some of the ideas: http://www.praxis-his.com/news/sparkGPL.asp But you don't have to implement the whole thing as an automated toolset, a lot of it can be paper-based or some other manual method such as just writing in a comment at the top of every function what the expected inputs and outputs are, then making sure (by inspection or by test procedures in the code itself, and preferably both) that those are indeed the things that happen in practice. As I said in my first post, quality systems are fundamentally about documentation. We all know what a popular subject that is. :( One aspect of the documentation in this case would be writing down how to prevent these things from happening. That's the first problem. If you can't do that then you're in real trouble, it probably means that you don't know _why_ the things are happening. But at least now you know what the real problem is. It has little to do with the code. It will take time and a little effort, but once it's done, then all you have to do is what you wrote down you would do. That just takes discipline. Admittedly this is another relatively unpopular concept in the programming community. :) There are very many places to start looking at quality systems, but as we are in the very early stages I suggest that background reading about the issues would be more appropriate than diving into projects developed using modified ADA. Here's one document which covers many of the issues: http://satc.gsfc.nasa.gov/assure/agbsec3.txt It's written in fairly general terms, and at first sight it can be a bit daunting. But what appears at first to be onerous, confusing and even irrelevant can in fact be a great saver of labour, and when you begin to understand where it's 'coming from', as they say in the USA, it will all start to make sense. There are many more sources of information about software quality assurance on the Web, but the first step must be to recognize that there is a problem to be solved. When that is done, the developers are in a position to apply the techniques needed to solve it. <footnote> Here in England we used to see "Made in Japan" on the base of lots of cheap, tacky, plastic products. The phrase became almost synonymous with mass-produced, poor quality products. About the time that I was born, the Japanese government passed a law which forced all Japanese manufacturers to work to the new 'quality systems'. The rest, as they say, is history. For most of my childhood I was immersed in a culture which held that "Made in Britain" meant "Good", while "Made in Japan" meant "Rubbish". In my teens, I began to wonder why my British made motor-cycle leaked more oil and broke down more often than my friend's Yamaha. Later, I wondered why the Japanese seemed to be able to bring new products to market so much faster than the British, and sell them cheaper, and in such large volumes. None of the British motor-cycle manufacturers could compete with the Japanese onslaught and every one of them went bankrupt. The few motor-car manufacturers here which did survive, if they can be said to have survived, have only done so by getting huge handouts from the tax payer. Our consumer electronics industry all but disappeared and the term "Made in Japan" is no longer something which provokes derision. All this was the direct result of the implementation of quality systems - elsewhere. It's the stuff of industrial revolutions, like when they moved from horses to steam, or from armies of clerks with their quill pens, to computers. And it's really rather easy to do, and cheaper, and quicker, than not doing it. </footnote> -- 73, Ged. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
