Software Design 2e - DIM

20The nature of the design processcases, the living conditions may also be little better or even worse, owing to architecturaldesign decisions to construct the tower blocks with relatively untried materials.So removing the original problem has revealed or created new ones that are even lesstractable. There is sometimes a similar effect during maintenance of software systems;adding one relatively innocuous feature may subsequently require massive redesign ofinternal data structures and reorganization of subprograms.Rittel and Webber identified ten distinguishing properties of wicked problems,most of which can be seen as applying equally well to software design (Peters andTripp, 1976). The following properties, taken from their list, are particularly relevant.nnnnnThere is no definitive formulation of a wicked problem. The difficulties of specifyingthe needs of software-based systems are well known, and the tasks ofspecification and design are often difficult to separate clearly. Rittel and Webberalso make the point that the specification and understanding of such a problem isbound up with the ideas that we may have about solving it – which is why the simplelife-cycle model in which the task of specification is followed neatly by that ofdesign is rarely a realistic description of actual practices.Wicked problems have no stopping rule. Essentially this property implies that thereis a lack of any criteria that can be used to establish when the solution to a problemhas been found, such that any further work will not be able to improve uponit. For software, this is demonstrated by our lack of any quality measures that canbe used to establish that any one system design is the ‘best’ one possible.Solutions to wicked problems are not true or false, but good or bad. For many scientificand classical engineering problems, we may be able to identify whether asolution is correct or false. Software designs usually come in ‘shades of grey’, in thatthere are usually no right or wrong solutions or structures. (This point will beevident to anyone who has ever had cause to mark a set of student programmingassignments.)There is no immediate and no ultimate test of a solution to a wicked problem. Thedifficulties inherent in any form of system evaluation process adequately demonstratethat this is very much a characteristic of software. Indeed, even an apparentlysimple exercise such as a comparison of the features of (say) a number of webbrowsers can demonstrate the multi-faceted way in which their features need to beclassified and compared, and the lack of any one criterion that can be used to establishwhich one is ‘best’ in any sense.Every solution to a wicked problem is a ‘one-shot operation’, because there is noopportunity to learn by trial-and-error, every attempt counts significantly. This isparticularly true for large-scale software systems such as those dealing with majornational activities, for example paying pensions, collecting taxes, etc. The resourcesneeded to explore different options are simply not available, and it is rarely possibleto ‘unpick’ changes to operational practices once these have been implementedin order to meet the needs of such systems. Some good examples of the problems ofcreating and installing large public systems are illustrated in PAC (1999), althoughthe conclusions there (that better project management is the answer) are simplistic,and, indeed, reflect a failure to really understand that the problems are wicked ones!