The Symbian OS (779886), страница 96
Текст из файла (страница 96)
NET library or run-time environment forSymbian OS. And then there’s OPL, a very old and venerable programmingenvironment and there are more recent contenders such as Python. Thecommon theme of these interpreted languages is that they are less efficient interms of manipulating the bare metal of the device, but they require less of alearning curve to become productive.MOVING TOWARDS STANDARD C++451What I’ve seen is evidence that you don’t need to be anything like suchan experienced programmer to use them, indeed non-programmers such asjournalists and students of journalism or students of media or students of artsand technology are able to learn how to create quite impressive programs inPython from a course based on just one lesson per week, and that is part ofSymbian OS coming to the mainstream.18Creative Zoo or Software Factory?18.1 IntroductionThis case study takes a step back from Symbian OS itself to exploresome of the broader questions about how software is created.
Oneconsequence of the success of Symbian OS has been the rapid growthof Symbian, the company, and of its software engineering organization.From its small-company origins, Symbian has become a middle-sizedcompany, established in a global market. Success, inevitably, brings itsown particular slant to the perennial problems of how best to makesoftware.18.2 The Software ProblemLike all software companies, Symbian wrestles with the problems ofefficiency, effectiveness and predictability. Every software developmentorganization faces the same basic question: what is the right way toorganize so as to be as effective as possible at making and shipping greatsoftware? In other words, how should development teams be organized(or how they should organize themselves), with respect to the softwarebase and the need to continuously maintain, evolve and improve it? Andthere are softer questions too: what should the project culture be andhow should it feel to work in a project?These are not new problems and a lot has been written about them, butnonetheless they are difficult problems.
One reason they are difficult isthat they are ill-defined problems, not the kinds of problems with whichsoftware companies like to deal and problems with which, typically,software companies are bad at dealing. (It is always a mistake to seekengineering solutions to non-engineering problems.) They are not madeeasier by the fact that there is disagreement among practitioners abouteven the basics.454CREATIVE ZOO OR SOFTWARE FACTORY?Typically, software creation is counted as an engineering practice,which is to say one based on measurable, formal procedures and systems,although not necessarily formally mathematical.
(A dissident, formalistview is that it would better be classed as mathematical practice). Development methodologies therefore are engineering methodologies (processengineering and product engineering) which should deliver validatedsolutions to well-specified problems (customer requirements), predictablyand repeatably.There is a minority view that the very use of the word engineering in this context is a category mistake.
Software creation is not anengineering discipline but something more like a craft practice, carriedout by skilled professionals making intelligent, intuitive, but necessarily‘soft’ or ‘fuzzy’ or simply underdetermined decisions. Worse, it is notjust the case that requirements are often poorly specified; they are, inmany cases, unable to be specified before the development activity (i.e.outside the context of a proposed solution). Development methodologies, in this view, should be designed around these basic matters offact.The business demands imposed by the commercial context do nothelp to reconcile the differences. When software companies are productcompanies (it is easier when they are simply internal suppliers), theyare subject to the same commercial disciplines as any other business.Less orthodox approaches to requirements capture and design, based onprototyping and experimentation, trial-and-error and iteration, becausethey are inherently uncertain and therefore high risk, are in immediateconflict with a command and control business culture.
As much at issueas methodological questions, then, are cultural and sociological onesand the underlying questions of control and where it resides in theorganization.A final difficulty of the pure engineering approach is that whatever theother merits of the argument, there is no doubt that the underlying activityof actually writing software looks as much like an art as a science. It is fullof subtleties, is strictly non-deterministic, is highly context-sensitive, lendsitself to multiple possible solutions, and requires experience, expertise,imagination and inspiration.
These are the facts that underlie the familiarstatistics about individual programmer productivity. No matter what thebusiness needs, it simply is not possible to mandate software productivity.If proliferation of theory is an indicator that a research area is underdetermined by the available facts, then software practice is up there with thebest of them.
Development methodologies proliferate and it can be hardto sort quack remedies from principled alternative practices. Theoriesare rapidly inflated into fully marketed, patent medicines for all softwaredevelopment ills. Gurus abound and none of them agree about much atall. Metaphors abound too, from ‘design factories’ and ‘software factories’to ‘total quality’ and ‘Sigma 6’ to ‘Scrum’ and ‘Extreme’.TOO MANY DRAGONS45518.3 Too Many Dragons[Aho, Sethi and Ullman 1986] has a fire-breathing monster bearing thelabel ‘Complexity of Compiler Design’ on its cover. There are manydragons to slay in software development, of which the innate complexityof the endeavor is the fiercest and fieriest.
Presumably, complexity is alsowhat Stanley Lippman, the author of more than one well-regarded C++primer, is alluding to when he chooses Durer’s engraving of the knightand the devil for a frontispiece [Lippman 1996].But almost as fierce and fiery, and certainly as famous, is the dragon‘of poor programming productivity’, the problem to which [Brooks 1976]first drew attention and which, for example, [Gabriel 1996] confrontsin an influential essay, without reaching any very hopeful conclusions.Estimates of programmer productivity vary from 10 to a few hundred linesper month, or perhaps 1000 to 2000 ‘non-commentary source lines perprogrammer per year.’ As [Gabriel 1996, p. 127] points out, that is aboutfour lines a day – ‘There is a software crisis.’The phrase ‘software crisis’ was coined as long ago as 1968,1 andmost of the current software creation infrastructure has evolved in itsshadow, including the dominant operating systems, programming andmodeling languages, and analysis methodologies, not to mention themodern software–hardware infrastructure.2 All can be seen as part ofthe same calculated effort to move the practice of making softwarefrom a black-art to a well-founded science.
The ‘crisis’ was createdby the impossibility of reliably planning, implementing and maintainingsystems beyond a certain size and complexity threshold. Interestingly,another phrase coined at the same conference, by Doug McIlroy, oneof the pioneer creators of Unix, was ‘software engineering’. McIlroy alsoobserved that without some evidence of a components industry, there wasno sound basis for thinking of software production even as an industry(let alone an engineering industry) [Assmann 2003].Of course, what McIlroy had in mind was a research and engineeringprogram that might lead to an industry founded on the manufacturingof software out of components. Since components and composition ofcomponents explicitly underlie and underwrite today’s object-orientedapproaches (and, in fact, most other recent programming methodologyresearch too), it seems fair to say that McIlroy’s call has been heeded.But still, the striking fact is that, close to 30 years later and what shouldtherefore be a good way beyond the black-art and wizardry stage, thecrisis seems as strong as ever.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
