The Symbian OS (779886), страница 97
Текст из файла (страница 97)
It’s not so much that no solutions were1At an international conference of software professionals and academics called toaddress the question, ‘How can software be produced systematically?’ [Assmann 2003,p. 6]2Take your pick, but Unix first appeared in 1969; the PC in 1981; the C language in theearly 1970s; C++ in the early 1980s; and Java not until 1995.456CREATIVE ZOO OR SOFTWARE FACTORY?found, as that the problem has simply continued to grow exponentially.For every solution, it seems, there is an immediate test case problem forwhich, in one dimension or another, the solution is inadequate.There is extensive literature on the software crisis and on the proposedsolutions to it, from structured techniques to object techniques and reuse,along with a host of related approaches and methodologies, from ClassResponsibilities Collaborators (CRC) cards3 and patterns, to feature teams,to Extreme and Agile programming.
Abstracting the detailed differences,the common core of the radical solutions is an emphasis on incrementaland iterative development and the freeing of programmers to think,approaches which are promoted by a generally broad and probably wiseconsensus. But, as [Gabriel 1996] somewhat regretfully concludes, thereis little evidence that the industry overall is either pleased to hear theremedies or attempts to apply them in practice on any large scale. Onthe whole, they do not offer solutions that a traditionally managed andtypically ‘over-managed and under-led’ industry wants to hear.
It carrieson as it always has, even though eventually, as [Gabriel 1996, p. 128]puts it, ‘we’ll find that traditional software development methodologiesare among the least productive and possibly produce the lowest quality.’What drives the traditional software development methodologies arethe basic commercial imperatives of management control and processrepeatability and predictability. The problem is that these imperativesseem to be at odds with the practices which actually deliver bettersoftware productivity and quality.
Perhaps software is ‘just different’, butif Gabriel and others are right, achieving productivity and quality seem torequire non-traditional approaches to control. Traditional managementdoesn’t want to let go.18.4Software Development ApproachesOne argument, or perhaps it is more strictly a metaphor or anotheranalogy, which has proved very popular is that making software is abit like making buildings. Prefabrication and componentization are onlysmall parts of any answer as to how to do it better, more reliably ormore predictably.
Following the analogy of ‘habitability’, making ‘better’software means making software which is more elegant, more long-livedand more adaptable; on the analogy of buildings which do not fall down,reliable software does not fail unexpectedly; and predictability meanscompleting the job in something like the predicted time.This metaphor is at the heart of the software patterns movement, whichargues that not only is making software like making buildings, but thatit is an irreducibly human activity and team activity.
Relationships and3A good introduction is [Beck 1999].SOFTWARE DEVELOPMENT APPROACHES457interactions between individuals, and individual and team behaviors andall the subtleties and difficulties associated with them, come into playand must be managed by the software creation process in order for theprocess to succeed [Rising 1998, p. 143]. Different organizations havetried different approaches, including Extreme and Scrum4 programmingapproaches and similar team-based systems, which along with ideassuch as ‘creative chaos’ (as a tool for fostering innovation and creativitywithin the industrial organization) have been the subject of industrialexperimentation across many different industries in Japan.5 Teams, ofcourse, are just groups of collaborating individuals plus leadership (teamswithout leaders are groups) and the health of a team is a function of thehealth of its individuals plus the quality of its leadership.The common contention behind all of these approaches is that thecore processes of software development cannot be understood from apurely task-based perspective.
A broader perspective which explicitlymakes room for the ‘people’ dimension, as well as mapping task outputs(for example, an ‘artifacts, roles, actors, and agents’ model [Rising 1998,p. 122]) is essential to understanding what is an essentially dynamicactivity. Traditional process models, especially those such as ISO9000but including also the popular Capability Maturity Model (CMM), havetheir place but are not perfect at capturing software development as it isactually practiced and, indeed, as it must be practiced.Another point that these approaches all stress is that if making softwareis a creative process then it depends for its success (presumably) onenabling creative individuals to do the creating, and creativity is noteasily prescribed. A preponderance of strong personalities among thecreative people also means that command-and-control approaches aredoomed to fail, if not absolutely (some software will get made) thenrelatively (team potential will have been poorly exploited and softwarequality will be poorer than it could have been).Old-fashioned, waterfall development is very thoroughly and almostuniversally deprecated.
Full specification followed by full design followedby full ‘coding’ does not work, because ‘full specification’ and ‘full design’have both proven unachievable in practice. Iterative development, insome form or another, seems to be the only rational alternative [Rising1998, p. 148], allowing a full specification of the problem and a fullydesigned solution to emerge through successive cycles of partial designand implementation. However, in practice, software organizations likemost others have an almost insatiable desire for detailed specificationand up-front design, not to mention planning and budgeting, ahead ofany resource commitment.
The organization defeats itself, because it isrisk-averse and wants certainty, or relative certainty, when in fact it should4‘Scrum’, or ‘relay’, is an attempt to translate the Japanese word ‘sashimi’.At Nissan, Fuji Xerox and Matsushita for example. See [Nonaka and Takeuchi 1995],especially for the theory of creative chaos.5458CREATIVE ZOO OR SOFTWARE FACTORY?be organizing to manage uncertainty. But to many planners, uncertaintydoes not sound much like engineering. It is also easy to fall into the trapof seeking to control process artifacts, rather than managing processesthrough the people who implement them.Another problem is that iteration depends on short cycles, but oftenenough the short cycle is subverted by the planning process.
The implementation phase is repeatedly postponed for the sake of a little moreplanning certainty. The result is not a short cycle at all, but a traditionallong one (six to nine months, say), with a planning front-end whichlasts for six months out of nine, followed by a hasty development tail.Inevitably the tail turns out not to be short at all, development takesas long as it takes, and the overall cycle reverts to being a one-year or18-month cycle.Organizational fear of ‘randomness’ and the indeterminate or merelyunderdetermined fuels the urge to centralize and control, to legislate,plan and create metrics (define and measure!). Randomness, for wantof a better word, is a necessary part of the process of exploration.6Uncertainty, whether we like or not, is a given of creativity.
The creativefactory is probably an impossibility.7Building construction mixes art and science, but it also has anotherimportant dimension. ‘Ethical’ architecture is essential, because the buildings that architects create determine our physical spaces and, done badly,despoil our towns and cities. ‘Ethical software’ might be something wehad better start to consider too. Software increasingly permeates ourlives and, in some cases, is beginning to dominate and control them,not necessarily for the good.
Identity cards and ‘big’ databases are oneexample; software-driven munitions are another;8 as is the ‘Google inChina’ question.9 An ethical-software manifesto, if there was such a thing,would fit well with the original goals of the software pattern movementfor habitability and would fit well with the original aims of ChristopherAlexander in his architectural patterns work.106Error, indeed, is objectively indistinguishable from creativity, in so far as both areunderdetermined and only subjective measurement against a goal can tell one fromanother.
To stretch the point only a little, the software on the Ariane rocket made an error,not a creative leap; but in other circumstances, departure from the norm might be calledinspiration.7A factory is a place where mechanized production takes place, originally organizedaround the principle of machine-minding (‘satanic mills’, for example, with steam-drivenlooms), re-imagined by Henry Ford and others around the idea of the production line andthe factoring of the production task into simple actions performed by highly specializedbut unskilled labor. A factory has only lately been reinvented as a place where teams worktogether to meet their production targets.8Mobile phones are not ethically neutral.
Mobile phone access to emergency and rescueservices saves lives. But equally, mobile phones are increasingly being used to trigger bombsand as homing devices for remotely delivered munitions to target individuals.9How can we achieve the ‘borderless Internet’ when it runs up against state censorship?10The classic text is [Alexander 1979].WHAT MAKING SOFTWARE IS REALLY ABOUT459In some senses, the open-source and free-software movement is anethical movement, but in other senses it is more obviously mercantileand market-led and markets know no ethics.
But the hacker ethic (see[Himanen et al. 2002]) proposes a rather different work ethic from theconventional one: work is fun, programming is play and the passion forthe machine has a moral dimension.18.5 What Making Software Is Really About‘Shipping great software on time’, as [McCarthy 1995, p. 2] puts it, iswhat making software is all about.
But as he emphasizes, software ispeculiarly intangible. It is not simply ‘stuff’; it is embodied thought, ideaplus design plus implementation; each of which is an intellectual (notmechanical) process. What makes the process interestingly different fromother intellectual processes (thinking, writing and painting) is that beyonda certain level of size and complexity, it is necessarily a team activity.For McCarthy at least, the word ‘development’ (as in ‘software development’) is a clue to the nature of the enterprise, a dynamic process ofmaturation, in which what matures is precisely that embodied thought:as he writes in [McCarthy 1995, p.
85], ‘It’s the team ideation, graduallymigrating from highly individual (even private) notions toward a grouparticulation in the shipping code.’ This way of putting it will resonatewith anyone who has been involved in the software development process(and that means, as he says, ‘everybody on the team’, whether planning,scheduling, creating or validating the software product). The essentialdevelopment act is this development of individual ideas into embodiedintellect, productized thought: intellectual property, in other words.This is the view, of course, that sees making software not as anengineering process (although there are engineering aspects to it, asthere are in any construction process) but ‘as primarily a sociologicalor cultural phenomenon’ [McCarthy 1995, p.
87]. Perhaps more eventhan engineering ‘aspects’, there are some engineering fundamentalsinvolved. Machines are engineered constructs and all software is insome sense ‘soft machine’. But, nonetheless, if the software industry isfundamentally a creative industry, then there are necessary limits to howfar industrialization (and even formalization) can go. Every developer isfamiliar with the notion of the ‘death march’11 and it is hard to imaginethat anyone would willingly adopt it as a project model. But without adevelopment methodology that understands, and serves to support, thereality of the software creation process, it is probably the inevitable endfor all software projects.11The ‘death march’ is the bringing to final completion of a long and difficult projectand its repeated slippage as an ‘exhausted, physically and emotionally spent’ team marches,stumbles, and lurches to final shipping of the product [McCarthy 1995, p.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
