Time-to-market and security

Network effects have considerable influence on the behaviour of COTS software producers in particular: short time-to-market to exploit the first-mover advantage is crucial to establish a software product in the market and to profit from the network effects.

Incentives to be the first on the market and to establish one’s own products as de facto standards are very high. Studies in software development repeat the economic rationality that in market-driven development the primary goal is time-to-market¹⁷². Time-to-market is crucial not only for a new system but also for new product features or concepts in existing systems. Nor does time-to-market constrain only the initial release: market leaders must keep developing advanced features, bug fixes, and performance improvements in order to keep old customers satisfied and to win new ones¹⁷³. In fact, competition for best time-to-market is perpetual.

Short development cycle due to time-to-market pressures is a general phenomenon in market-driven development, especially in the

Understanding secure software development 77

174 This was subject to much interest in the late 1990’s and has been reported especially by Cusumano and Shelby, Microsoft Secrets, p. 15; Blackburn et al., Improving Speed and Productivity of Software Development, p. 875; Kuvaja et al., Specific Requirements for Assessing Embedded Product Development, p.

74; Botting, On the Economics of Mass-Marketed Software, p. 327.

175 Cusumano and Yoffie, Competing on Internet Time, p. 298-299. Shortening development cycles in Internet software companies has been reported also by MacCormack in Product Development Practices that Work and by MacCormack et al., Developing Products on “Internet Time”, p. 144-145, and in relation to application and smaller niche software developers in Baskerville et al., How Internet Software Companies Negotiate Quality, p. 51, and Baskerville and Pries-Heje, Racing the e-bomb, p. 55.

176 This has been emphasised by Fred Schneider in Trust in Cyberspace, p. 67 and 72.

177 Viega and McGraw, Building Secure Software, p. 26 and 35 The complexity of software engineering under conflicting requirements has been emphasised, e.g., by Barry Boehm in Software Engineering Economics, p. 20-21.

178 Baskerville et al., How Internet Software Companies Negotiate Quality, p.

51; Wheterbe and Frolick, Cycle Time Reduction.

development of mass-marketed software (including software embedded in consumer electronics and telecommunications equipment)¹⁷⁴ and Internet software. Already in 1998 the development cycles have compressed from 24-36 months to 12-18 months for non-Internet related companies and even to 3-6 months for companies involved in eCommerce and creating and maintaining Web portals¹⁷⁵. The high incentives to be first to market and to establish one’s own products as de facto standards means that software development practice easily becomes distorted to maximize functionality and minimize development time, with little attention paid to other qualities (especially non-functional requirements such as security and safety)¹⁷⁶ or project goals that conflict with functionality and time-to-market (fundamentally so in the case of security because more security limits functionality)¹⁷⁷. Anecdotal evidence shows that companies may compress their quality assurance (QA) practices when the priority is a shorter development cycle¹⁷⁸. A shorter development cycle results in reduced quality and security, especially if ad hoc processes are used – as they typically are – in the prioritisation and cost/impact

Regulating Secure Software Development 78

179 Sawyer et al., Improving Market-Driven RE Processes, p. 227.

180 The way software-consuming organisations interact with software producers has changed due to the increased product attention. Traditionally, early and close links between users and developers have been considered critical. Today, software consumers and producers use a variety of intermediated means to communicate their needs to developers. For example, packaged software developers build to requirements gleaned from a variety of sources, including help-desk call-log analysis, market research, product reviews, and user groups, of which direct customer contact is one of the least likely means. (Sawyer, 2001, p. 100, see also Keil and Carmel, 1995, p. 33–44) This is one of the major dilemmas: the challenges of developing software for larger markets is to satisfy the end user although contact with the end user is limited (Natt och Dag, Elicitation and Management of User Requirements in Market-Driven Software Development, p. 19).

181 See, e.g., Blackburn et al., Improving Speed and Productivity of Software Development, p. 884; Schneider, Trust in Cyberspace, pp. 68-74

182 Natt och Dag, Elicitation and Management of User Requirements in Market-Driven Software Development, p. 26. This is often because time pressures change the way requirements are approached. Traditionally, requirements analysis has been based on the assumption that a large company

assessment of sometimes conflicting requirements such as quality/security costs and time-to-market¹⁷⁹.

For example, despite the wide acknowledgement of the advantages of good requirements specification early in the development phase, the documentation and maintenance of requirements tend to be sketchy. Requirements that are proposed, invented, or designed are communicated within the development organisation to a large extent by word of mouth; they are not elicited or played back to the customer since in market-driven development users (referred to as customers) are typically unknown during the development phase (there may not even be a user until the first release of the product)¹⁸⁰. Even though there is increasing research on requirements engineering due to the wide recognition of the centrality of requirements specification to the whole development process already in the late 1990s¹⁸¹ and improvements have been made, many of the general challenges in traditional requirements engineering are adopted by the market-driven development organisation (e.g. requirements are erroneous, errors are detected late, and ambiguities are difficult to resolve)¹⁸².

Understanding secure software development 79

or institution orders a large software system from either an external vendor or internal IT department, using a requirements specification as a contract.

However, in market-driven development there is no contractual situation, and requirements specifications are rarely written (Carlshamre, A Usability Perspective on Requirements Engineering, p. 57-58; Natt och Dag, Elicitation and Management of User Requirements in Market-Driven Software Development, p. 21). Dahlstedt et al. in Market-Driven Requirements Engineering Processes for Software Products – a Report on Current Practices, partially verify many of the characteristics of market driven requirements engineering in a first stage industrial survey of small and fairly new market-driven development companies in the Swedish software industry.

183 This has been reported for market-driven software development in general (see, e.g., Natt och Dag, Elicitation and Management of User Requirements in Market-Driven Software Development, p. 17; Potts, Invented Requirements and Imagined Customers; Karlsson and Ryan, A Cost-Value Approach for Prioritizing Requirements, p. 68) as well as software for electronic commerce and for web portals (see, e.g., Cusumano and Yoffie, Competing on Internet Time, p. 14, and 224-234; Baskerville et al., How Internet Software Companies Negotiate Quality, p. 52). In interviewing companies using Internet speed development techniques Baskerville and Pries-Heje, Racing the e-bomb, p. 56-57, found that vague requirements continue throughout projects. This is one cause for release orientation.

184 This argument has been raised, e.g., by Ross Anderson, a Professor of Security Engineering at the Computer Laboratory of the University of Cambridge, in a seminal paper combining economics and information security in 2001, Why Information Security is Hard p. 2.

185 Schneider, Trust in Cyberspace, p. 194.

An important consequence of the shortening development cycle (due to first-to-market being essential) is the tendency towards release-oriented development¹⁸³. Constantly striving to be ahead of competitors, the market-driven development company frequently delivers new and improved releases (containing bug fixes and new features) of software products. The development resources – especially time-to-market, but also budget – are typically fixed¹⁸⁴, at the expense of lower-priority requirements. Each feature is examined to determine whether its inclusion in the product is necessary for the product to be competitive in the marketplace.

Generally, those features with direct customer appeal win; subtle, hard-to-demonstrate and pervasive properties – such as security – tend to be rejected¹⁸⁵. They are put of from one release to another

Regulating Secure Software Development 80

186 This has been pointed out by on the basis of personal experience, e.g., by Preston G. Smith in From Experience 1999, p. 223 and has been verified by Baskerville et al., How Internet Software Companies Negotiate Quality, p. 55, in an interview of software developers and project managers of nine application and smaller niche software companies using Internet speed development practices. See also Carlshamre, A Usability Perspective on Requirements Engineering, p. 58.

187 This is what Baskerville et al., How Internet Software Companies Negotiate Quality, p. 53, argue on the basis of interviews of software developers and project managers at nine application and smaller niche companies using Internet speed development practices.

188 Shapiro and Varian, Information Rules, p. 169.

189 Shapiro and Varian, Information Rules, p. 169.

in order to meet the release date. This feature or requirement slippage should not come at the expense of quality and security, even though this easily is the case¹⁸⁶. Security tends to be ignored because it would require that more time and money be put into development work that is beneficial only in the long run (no immediate returns). Time-to-market considerations discourage the inclusion of security features and encourage the postponement of security to later releases – if they are considered at all.

A release orientation is necessary for a start-up company since it cannot generate revenue before it produces functionality, even where this is somewhat unreliable. The code of the first release lacks security because any issues that can be postponed, including quality and security, are disregarded¹⁸⁷. For an existing (or even dominating) firm, the frequency and timing of new versions and upgrades is a way to control the length of the cycle of customer lock-in into one’s products as economic theory explains¹⁸⁸. It is necessary to produce new releases and upgrades to prevent aggregate customer lock-in from getting too low at any point of in time, because the optimal time for a competitor to enter the market and to attack the installed customer base of the existing firm is when the aggregate customer lock-in is low¹⁸⁹.

However, the quality aspect of security is placed high on the agenda when a security problem left in a software product has been publicly broken and is being exploited by attackers. Unfortunately, a patch

Understanding secure software development 81

190 Viega and McGraw, Building Secure Software, p. 16.

191 It has to be noted that even though the distribution of a patch is cheap, the creation of a bug fix is not. This is what the research on the ROI of security investments hinted. The development and testing of patches is expensive if it is done for even nearly all of the different configurations and environments of the customers. There is a strong customer reliance on the vendor to test the patches in many environments before their release especially if the patch is streamed (automatic update). However, since most bugs are harmless and go unnoticed this cost is relatively low compared to removing majority of bugs before release.

is essentially the only option used when this occurs. According to John Viega and Gary McGraw¹⁹⁰, the problems of this pervasive ‘penetrate-and-patch’ approach are, among other things, that not all problems are reported to the developers that make the patches, that patches often introduce new problems because they are also rushed out as a result of market pressures, that often only the symptom of the problem gets fixed leaving the cause unaddressed, and that patches often go unapplied or are otherwise ineffective.

But it is no surprise that this penetrate-and-patch approach still is so pervasive. Not only does it help in getting products onto the market more quickly by skipping initial security considerations that seem to slow down development, diminish functionality, and give revenue only in the long run, but patches are also cheap to distribute.

Distributing a patch for a piece of software is a lot cheaper than for traditional commodities, due to the immaterial nature of the good and consequently the virtually zero marginal cost of transmission.

Developers can make patches available to the web or e-mail them out to customers and the cost of installing the patch falls on to the customers¹⁹¹.

A fast cycle time together with a release orientation is something that is impossible to achieve in a serial process. Parallel development is used widely in release-oriented development: traditional serial phases are split and assigned to separate groups of developers, which then

Regulating Secure Software Development 82

192 About parallel development in market-driven process in general, see Blackburn et al., Improving Speed and Productivity of Software Development, p. 878, and in Internet software development especial Cusumano and Yoffie, Competing on Internet Time, p. 14, and Baskerville et al., How Internet Software Companies Negotiate Quality, p. 52.

193 Baskerville et al., How Internet Software Companies Negotiate Quality, p.

54.

194 See, e.g., Natt och Dag, Elicitation and Management of User Requirements in Market-Driven Software Development, p. 18; Carlshamre, A Usability Perspective on Requirements Engineering, p. 59.

perform them simultaneously¹⁹². Quality assurance and testing are also done in parallel with other development phases; if a rapidly approaching release date forces the company to shorten development phases, quality assurance and testing also get short-circuited¹⁹³.