Budgen, Software Design Methods
Total Page:16
File Type:pdf, Size:1020Kb
David Budgen The Loyal Opposition Software Design Methods: Life Belt or Leg Iron? o software design methods have a correctly means “study of method.”) To address, but future? In introducing the January- not necessarily answer, this question, I’ll first consider D February 1998 issue of IEEE Software,Al what designing involves in a wider context, then com- Davis spoke of the hazards implicit in pare this with what we do, and finally consider what “method abuse,”manifested by a desire this might imply for the future. to “play safe.”(If things go well, you can take the credit, but if they go wrong, the organization’s choice of method can take the blame.) As Davis argues, such a THE DESIGN PROCESS policy will almost certainly lead to our becoming builders of what he terms “cookie-cutter, low-risk, low- Developing solutions to problems is a distinguish- payoff, mediocre systems.” ing human activity that occurs in many spheres of life. The issue I’ll explore in this column is slightly dif- So, although the properties of software-based systems ferent, although it’s also concerned with the problems offer some specific problems to the designer (such as that the use of design methods can present. It can be software’s invisibility and its mix of static and dynamic expressed as a question: Will the adoption of a design properties), as individual design characteristics, these method help the software development process (the properties are by no means unique. Indeed, while “life belt” role), or is there significant risk that its use largely ignored by software engineers, the study of the will lead to suboptimum solutions (the “leg iron”role)? nature of design activities has long been established Robert L. • [email protected] Trends Glass • Computing (At the risk of being immediately categorized as a as an interdisciplinary topic in its own right, with a well- grammatical pedant, I will use “method” to mean “a established academic journal (Design Studies). way of doing something,”rather than using the more EDITOR: pretentious-sounding “methodology,” which more Continued on page 133 136 IEEE Software September/October 1999 0740-7459/99/$10.00 © 1999 IEEE of course, multitier client-server systems using these valuable introduction to and reference for its subject technologies. The authors also devote 200 pages to matter. Its secondary purpose seems to be lobbying comparing Corba and Java ORBs and their middle- for Corba as the middleware solution. Separating hype ware competitors such as Sockets, HTTP/CGI, Servlets, from information is left to the reader. On the other RMI, Caffeine, and DCOM. hand, this appears to be the status quo with most pub- Because the book intentionally focuses on Java lications during this time of middleware holy wars. and Corba solutions, it has only one token chapter Also, because the book is based on a Borland/ on interoperability between a C++ server and a Java Visigenic Corba implementation, the code is written client. The book also includes a CD containing source specifically for these packages. If you are using an- code for its examples and evaluation copies of other vendor’s package, such as Iona’s Orbix, you will ♦ Borland/Visigenic VisiBroker for Java and C++ need to do a bit of translation—which can be frus- (version 3.1), trating at times. If you are a Corba newbie, one way ♦ Borland/Visigenic CORBA Naming Service, to hasten the learning process is to read the book in ♦ Symantec Visual Cafe PDE (Professional De- parallel with your ORB-vendor’s tutorials manual and velopment Edition), some additional Corba literature. Such useful com- ♦ IBM Visual Age for Java, panions include CORBA Distributed Objects: Using ♦ Borland JBuilder Client/Server, Orbix, by Seán Baker (Addison Wesley Longman, ♦ Java Development Kit 1.1, 1997) and Sams’Teach Yourself CORBA in 14 Days, by ♦ Connect Software FastForward JDBC driver, Jeremy Rosenberger (Sams, 1998). ♦ Netscape Enterprise Server, In spite of the previous nits, Client/Server Pro- ♦ Netscape Communicator, and gramming with JAVA and CORBA is one of the best ♦ InstallShield Java Edition. books available on its subject. Nearly a year after its release, it is still rated highly in Internet newsgroups and by professionals using it to develop real-world BEHIND THE HYPE distributed-systems solutions. If you want to use Verbose at times, with a lot of pro-Corba propa- Java and Corba as your middleware solution, this ganda to wade through, the book is nevertheless a book is well worth reading. ❖ Continued from 136 sence of true or false solutions) are readily recog- nizable facets of software development. Studying the problems of design in different do- ♦ The opportunistic nature of much observed mains has produced three concepts that are partic- problem-solving activity.3 Basically, this means that ularly important in the context of the arguments as a solution’s form emerges, the problem-solving that I am putting forward: strategy is adapted to meet the new characteristics ♦ The need to assume the likely outcome of de- that are revealed. sign in developing the form of a solution.1 I sometimes These three concepts challenge the oft-encoun- liken designing to trying to reverse-engineer some- tered belief that good software engineering design thing that has not yet been developed! In other words, solutions will most likely come from systematically if we had a solution of this form, what do we think its following a prescriptive procedural method. However, elements and structure might look like? (I often adopt we can perhaps take comfort (admittedly of a some- the analogy of designing a clockwork mechanism for what limited kind) in that workers in other disciplines a watch to illustrate this. Given a description of its ex- also recognize the difficulties that are implicit in de- ternal form, how do we develop the escapement sign activities! mechanism and the balance wheel?) ♦ The “wicked”nature of any design process.2 In a wicked problem, a solution’s different aspects are HOW CAN DESIGN KNOWLEDGE so extensively interconnected that in adopting a BE TRANSFERRED? particular solution to any one part of a problem, the resulting interactions with the problem itself might Here indeed lies the rub. Back in the days (the make the task of solving it even more intractable. late ’60s and early ’70s) when people recognized The original concept arose in the context of social that a systematic approach to software develop- planning, but many characteristics of a wicked prob- ment was needed to cope with larger-scale projects, lem (such as the lack of a stopping rule and the ab- it became necessary to find ways of promulgating September/October 1999 IEEE Software 133 and encouraging the adoption of desirable prac- this department’s context.) One resulting question tices, such as structured programming. A procedural is, “How did these designers acquire their expertise, form (do this, then do this, then...) was one that read- and how much did observation, experience, or use of ily lent itself to this role and had the further advan- methods contribute?”Could this possibly imply that tage that it could be relatively easily conveyed developing generic design skills might be more im- through books and courses. Indeed, methods em- portant than using methods to transfer procedural ploying this form, such as Michael Jackson’s JSP knowledge derived from the experiences of others? (Jackson Structured Programming) and the early work of Ed Yourdon and his coworkers, met some real needs. By the late ’70s, use of the procedural THE EMPIRICAL VIEW form was perhaps not so much established as en- trenched. Even so, there were “good” practices that Given that the adoption of systematic evaluation did not readily lend themselves to such a form. practices in software engineering has been, and Perhaps the most obvious one was (and still is) in- continues to be, a slow process, it is perhaps not sur- formation hiding, for which no satisfactory form of prising that little work has been published that eval- procedural development practice has yet been uates design methods. Indeed, the very idea of con- devised. ducting any form of evaluation of how a design In reaction to such shortcomings, the approach method is used raises questions about what can to method development in the ’80s was essentially usefully be evaluated. Should we be concerned with “pile on more” (more diagrammatical forms, more a method’s ease of use, or with the quality of solu- models, and, alas, more complexity). A few years ago, tions produced (and the criteria for deciding this), I performed an analysis of design methods that in- or with scalability to larger problems, or…? volved modeling the transformations between de- If we examine the (admittedly limited) empirical sign model states for different methods.4 This analy- material available, two conclusions emerge: sis revealed a marked increase in the complexity of ♦ Studies of actual design activities have ob- both the states and the transformation activities for served only limited use of method practices and later design methods. Arguably, much of this com- have clearly indicated that experienced designers plexity stems from what I consider to be the para- are highly likely to employ opportunistic strategies.7 dox of object orientation, which seems to provide ♦ Studies of method adoption suggest that a excellent paradigms for analysis and implementa- method’s practices might be modified significantly tion but presents major difficulties for the designer! in use.8 (You can view this as either positive—if you Although we academics might be reluctant to believe that design practices should not be over- admit this, procedural design methods also provide constrained—or negative—if you are concerned a relatively tractable basis for teaching design and, about ensuring consistency of practice to aid future equally important, to help devise examination ques- maintenance!) tions.