Let me take a somewhat extreme position here to try and delve into some of these issues:
> Consider the SEI's stress on "move to the left" as shown at > http://www.sei.cmu.edu/director/aboutSEI.html > and the whole idea of software engineering processes and the use of models and > techniques such as Object Orientation and Cleanroom Software Engineering processes. "SEI advocates less testing" is clearly the headline. "Testing costs money so to cut costs by doing less testing." Sounds like the SEI are into shipping buggy software? I find this position strange in a way. Clearly we still have the constructivist vs. pragmatist divide here. The constructivist approach is exemplified by the Waterfall model with its obsession with Tayloristic management approaches and a blame culture. None the less testing is a critical factor in final acceptance. The pragmatist approach is exemplified by eXtreme Programming (XP) with its total obsession with unit testing. Any test driven development approach replaces the formal methods of the constructivist approach with a good unit test framework. Over the years having tried both styles of development, the actual development of small to medium sized bits of software is far better handled by the evolutionary approach and test driven development. Quoting Gall: A complex system that works is invariably found to have evolved from a simple system that worked ... A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. Gall J (1978) Sysytemantincs: How systems work and especially how they fail. Quadrangle/The New York Times Book Company. ISBN 0-7045-0331-X Despite this, very large systems do need some decomposition before the parts can be constructed and this is where the Waterfall-style and like approaches have usefulness. Perhaps it is possible to define small to medium sized software systems as ones where a single software architecture covers the description of the highest level view of the system? Thus the following is true in some sense. > The problem should be and can be solved and brought and kept under intellectual > control before ever being commited to a given technology (read: code). As Fred > Brooks said so well: "the hard thing about building software is deciding what one > wants to say, not saying it." He also said: "The central question in how to improve > the software art centers, as it always has, on people." at > http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html then he > further notes the need for great designers - note he did not say great programmers. Why the need to separate designers and programmers? In my book programmers are designers. > Even in the olden days coding was only about 10 percent of total effort. Part of the problem as I see it is that software engineering is a discipline based on out dated and out moded technology that applies to only about 10% of software systems developed. It may be that that 10% of systems take up 80% of the budget but there are still more systems being developed than software engineering covers. The tools and techniques of 1960s software development are not a good foundation for software development models in the 1990s let alone now in this millenium. The separation of design and code which happened in the 1960s is not an appropriate model for contemporary software development. > So if the goal is better quality software, then the better psychological question > to study is why programmers reject proven formal techniques and continue their > brute force and awkwardness ways believing they can intellectually overcome > problems of complexity. That and sweat. Formal processes are well understood in > academia but not so widely practiced in industry. Why? What are the psychological > factors? It's not the fear of lack of time since it is usually the case that doing > things right the first time is faster/better/cheaper than a less formal approach. > If you can solve that problem and get the software development community to adopt > formal processes for ordinary development, you will have done a service worth > billions of dollars per year. Reference > http://www.computerworld.com/softwaretopics/software/story/0,10801,72390,00.html . What are the formal processes that people talk about? There is often this academia used formal approaches (good) industy does use formal approaches (bad) position. Are we talking about formally specifying everything in Z and then translating this into code? Software designers like using source code to work with. It is the medium of control. UML diagrams and the like are used to communicate they are rarely used to actually design -- except perhaps for personal doodles to try out different ideas, effectively communicating with ones self. UML diagrams support the design process admirably but they are not the tool of construction -- except for those designers who can't program. Perhaps the advocacy of certain techniques by certain people is due to the fact that people who are not actually able to do the job are in positions of control? > Engineering and formal processes beat human force and intellect almost every time > with a few notable exceptions yet we continue to focus on better human intellectual > techniques with all its known limits (e.g. max variables one can juggle) instead of > better formal techniques and the reluctance to use them. For instance most of us > can do long division with decimal points via the memorized formal process we all > learned in grade school but it exceeds most of the population's intellectual grasp > as to why we move decimal points, borrow, etc which do allow us to solve problems > beyong our ordinary intellectual capacity to solve. We are not reluctant to follow > that process yet we programmers are reluctant to do all those drawings etc which > have been designed to overcome our intellectual limits. I find this paragraph a bit bizarre. Human force and intellect are all that there is. Engineering and formal process are about providing structures for humans to use their intellect in with better efficiency and efficacy they do not and cannot replace human design. Many have tried in the past to say that it can but this has been an attempt to provide places in the sofware development process for people who cannot actually do the job. All attempts at de-skilling the design/programming processes are essentially economic and political moves -- cut the costs and cut the power of the people who can do to ensure that accountants stay in power. Process is a tool to support productivity. It is a tool to aid reuse. A good process is essential to good software. It is just that I think scientific method is a better process architecture than production line for developing software. Obviously (!) I am now solidly in the pragmatist (Gall, see above) camp. I and my team evolve software from small systems that work and act as scale models of the final system to final systems. We use test driven development as the realization of scientific method. Unit tests provide our requirements specifications and allow for simple regression testing. The confidence provided to programmers by being able to evolve software in the knowledge that the testing framework is there really aids speed. Clearly the unit tests must be evolved with the code to do otherwise is to revert to Waterfall. SEI clearly still see testing as something designers and programmers don't want to do. I think they must be wearing blinkers. Once programmers have experienced a good method using test driven development they generally fall into it as the natural method of development. Where they fail in the method is when the desire to reach a sub-goal of the development outstrips the discipline of evolving test and code together. I would suggest that a good experiment to undertake would be to find out under what emotional / psychological factors developers slip out of the test driven development philosophy. As to Java, that is another email. -- Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8680 8712 Cygnet House Fax: +44 20 8680 8453 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act
signature.asc
Description: This is a digitally signed message part
