sign in sign up
<<
Home , Design knowledge, Software design

David Budgen The Loyal Opposition Methods: Life Belt or Leg Iron?

o software have a correctly means “study of method.”) To address, but future? In introducing the January- not necessarily answer, this question, I’ll first consider 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 (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 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 • (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 (). 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 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 ++ 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 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 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 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 . A procedural is, “How did these 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 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 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. (To continue in this vein of honesty, while One distinct peculiarity of is the teaching about design might be pedagogically at- extent to which commercial interests have domi- tractive, if by no means easy, knowing how to use a nated the codifying of associated practices. Many design method looks better on a student’s CV!) Only of the more widely known design methods, such as in the ’90s have we seen attempts to develop other /Structured Design, JSP, and paradigms for transferring design knowledge, Objectory, have been developed and marketed mainly through patterns and . How- largely by consultancies and commercial organiza- ever, our present portfolio of software design prac- tions. This situation has few parallels in related areas tices still has little that really addresses those design such as requirements elicitation or . characteristics I identified previously. Although this clearly suggests that industry in par- As a final comment on our practices, consider the ticular perceives a real need for design skills, it does observation of both Fred Brooks5 and Bill Curtis and not create the most objective forum for considering his colleagues6 that software development often de- the question of evaluation. We need to increase the pends on a number of exceptional designers use of empirical studies in this area, while accepting who “think on a system .” (The additional ob- that evaluation is itself a wicked problem, for which servation from Curtis that such people might not be we should therefore not expect to obtain true or particularly good programmers is also significant in false answers.

134 IEEE Software September/October 1999 WHERE NEXT? of the evident disillusionment with CASE tools. A fur- ther barrier to success seems to be . Just If we accept these arguments, we might conclude what does an object or procedure (method, subpro- that software design methods are at least straining gram, and so on) look like when viewed as a 2D or 3D the limits of their effectiveness, and indeed might projection? Despite these problems, tool support will have overshot them. So what other factors might likely be needed to make both patterns and architec- influence our search for more effective approaches tures widely usable and to provide the speed of de- to developing design expertise? velopment increasingly demanded. Can such tools One factor must be the question of how software also help develop and transfer expertise? will be developed in the future. Procedural software design methods are implicitly predicated on a hand- o return to the question with which I started, is crafted approach to , and Tnot now the time to accept that the life belt has driven primarily by technical factors. However, the become somewhat waterlogged and is likely to act growing emphasis on reuse and components and more as a leg iron? And if, as a corollary to this, we the associated influence of organizational factors9 consider that procedural methods have no future, offer major challenges to this assumption. Designing what might take their place? How can we break the a system to reuse existing components becomes a mold—how do we stop pretending that designing very different process (but not necessarily a less cre- software is largely a matter of following a set of well- ative one). It also leads to the complementary ques- defined activities, and recognize it as a creative tion of how we should design components for reuse. process that requires us to find ways to develop the As these cultural shifts begin to establish themselves, design skills needed to build the software systems the use of opportunistic forms and the adaptation of the future? of method practices I identified previously will likely This leads to another question: How can we iden- become even more marked, suggesting that reliance tify, grow, and encourage those talents needed for on methods will not remain a realistic option. the great designers who will create elegant and ef- So, if the software design method might be be- fective solutions to problems? To make real progress, coming an anachronism (if it isn’ already), what we need to find an answer to this question. (And other means are available for transferring design ex- note that, in the true spirit of the wicked problem, perience and knowledge? attempting to answer my initial question has merely ♦ (or idioms). These perhaps led to new ones!) ❖ offer a closer analogy to the way that we teach de- sign in a programming context (“this is the type of REFERENCES problem where this looping construct is appropri- 1. .C. Jones, Design Methods: Seeds of Human Futures, Wiley Interscience, New York, 1981. ate...”). However, the descriptive forms used to 2. H.J. Rittel and M.M. Webber, “Planning Problems Are Wicked record design solutions usually lack the well- Problems,” Developments in Design Methodology, N. Cross, ed., defined syntax and semantics of a programming John Wiley & Sons, New York, 1984, pp. 135–144. 3. B. Hayes-Roth and F. Hayes-Roth, “A Cognitive Model of language. So, although design patterns should be Planning,” , Vol. 3, 1979, pp. 275–310. a part of , they will not be suffi- 4. D. Budgen, “’Design Models’ from Software Design Methods,” cient in themselves. Design Studies, Vol. 16, No. 3, July 1995, pp. 293–325. ♦ Design architectures. The concept of software ar- 5. F.P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, Vol. 20, No. 4, Apr. 1987, pp. 10–19. chitectural style might yet prove to be more useful 6. B. Curtis, H. Krasner, and N. Iscoe, “A Field Study of the Software than that of the pattern, although it might also pro- Design Process for Large Systems,” Comm. ACM, Vol. 31, No. 11, vide the syntactic and semantic framework for pat- Nov. 1988, pp. 1268–1287. 7. S.P. Davies and A.M. Castell, “Contextualizing Design: terns. (But if so, please, can we agree to stop using such Narratives and Rationalization in Empirical Studies of Software grammatical monstrosities as “architecting” and “ar- Design,” Design Studies, Vol. 13, No. 4, Oct. 1992, pp. 379–392. chitected”?) Architectural concepts seem able to pro- 8. J. Iivari and J. Maansaari, “The Usage of Systems Development Methods: Are We Stuck to Old Practices?” Information & vide a powerful framework for teaching how design Software Technology, Vol. 40, No. 9, Sept. 1998, pp. 501–510. solutions can emerge for a given type of problem. 9. A. Lynex and P.J. Layzell, “Organisational Considerations for ♦ Tools. To date, the use of tools to support design Software Reuse,” Annals Software Eng., Vol. 5, 1998, pp. 105–124. activity has largely reflected pencil-and-paper prac- David Budgen is a professor of software engineering and the head of the Department of at Keele Uni- tices, but with the disadvantage of having a less adapt- versity. Contact him at the Computer Science Dept., Keele able form. This disadvantage has probably led to some Univ., Staffordshire, ST5 5BG, UK; [email protected].

September/October 1999 IEEE Software 135