http://computer.org/itpro

JULY ❘ AUGUST 2006JULY ❘ AUGUST 2006

High-Speed Software Development

Context-AwareMobileServices

High-Speed Software Development

Context-AwareMobileServices

IT Graduates Aren’t Measuring Up p. 64IT Graduates Aren’t Measuring Up p. 64

July ❘ August 2006 IT Pro 291520-9202/06/$20.00 © 2006 IEEE P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

High-Speed SoftwareDevelopmentPractices: WhatWorks, What Doesn’t

Richard Baskerville, BalasubramaniamRamesh, Linda Levine, and Jan Pries-Heje

F ast development, low cost, and high qual-ity have long formed a tripartite tensionamong software engineering goals. Formost products, companies use traditional

methods to maintain this tension, but productssuch as Web portals, which are developed literallyon Internet time, require a lighter touch. In thepast decade, development cycles for such prod-ucts have shrunk from a year or more to one tothree months, to accommodate rapid and signifi-cant feature changes.

Coincidentally,there is a growing interest in agilemethodologies such as Extreme Programming andScrum that are more formal than hacking and lessformal than traditional methods.Although agile andplan-driven methods are likely to be successful intheir home ground, in many projects a hybrid mixof these methods might be most appropriate. We

believe it is critical for developersto understand the pros and consof some of the more popular prac-tices so that they can better bal-ance quality, cost, and develop-ment speed, and avoid reinvent-ing solutions. Beyond the work of highly visible leaders, such asMicrosoft and Netscape, little isknown about high-speed soft-ware development—the proces-ses and steps to retaining qualityin this accelerated cycle.

To this end, we conducted an empirical study ofhigh-speed software development practices in UScompanies. As the “Anatomy of an EmpiricalStudy”sidebar explains,we first reviewed detailedcase studies of Internet software development in10 companies and then synthesized knowledge onbest practices for quality and agility.Table 1 showssix common problems these companies identifiedin high-speed development and the practices theyuse to address them.Although it might seem ele-gant to have each practice address a single prob-lem, the real world of high-speed softwaredevelopment is too messy to support such a crispcorrespondence. In fact, to a varying degree, eachpractice addresses each of the difficulties and com-panies tend to use practices collectively.

Many of these practices are not new, but theways in which companies combine them—oftenwith unprecedented intensity—have yielded dra-matic improvements in high-speed developmentenvironments.Each practice naturally has its indi-vidual pros and cons, as we describe, but whentaken together, they provide a competitive advan-tage to many software organizations.

PRACTICE 1: PARALLEL DEVELOPMENT AND FREQUENT RELEASES

High speed often requires overlapping, paralleldevelopment. The organization can developreleases in parallel or stage them onto the market

Six common practices—used in unique and often intense ways—offer an informal framework for firms facing Internet-time softwaredevelopment.

Anatomy of anEmpirical Study

Essential versusAccidental Software

Difficulties

Resources

Inside

30 IT Pro July ❘ August 2006

I N T E R N E T S O F T W A R E

such that design, development, and quality assurance takeplace simultaneously as well as sequentially through dif-ferent releases. Coding often begins while requirementsare still unsettled. Parallel development demands that theteam prioritize the feature set and defect fixes, complet-ing essential features and fixes immediately and postpon-ing less essential ones. This practice breaks softwaredevelopment into a series of smaller projects, each with asmall requirements set and a short development cycle.

Parallel development practices can unfold in severalways.One is to divide development phases (analysis,design,coding,and test) among teams and conduct them in assem-bly-line fashion. Another is to group related features intoa release and have one team perform all phases for one

release while other teams work on different releases.Thisapproach puts less emphasis on maintenance; it is simplyfaster and cheaper to reimplement successive versionsrather than maintain them.

AdvantagesBoth parallel development and fre-

quent releases are useful in relievingthe demands of time-to-market com-pression. A competitive software

market means pushing products out the door as fast as pos-sible. The idea applies to new systems and new softwareproduct features or concepts in existing systems.Latecomers must run faster to keep pace with the techno-

In the first phase of our study, we analyzedgrounded theory in high-speed softwaredevelopment. In the second phase, weapplied search conference techniques in adiscovery colloquium. We concluded with acomparative analysis of the data from bothphases, which helped us understand howpractices have evolved as solutions to com-mon difficulties in high-speed development. Because ouranalysis operates at a high level of abstraction based inethnography (grounded theory and action research), theresults tell the story of high-speed software development.

Data collectionWe began this phase by collecting data on case studies

of high-speed software development at 10 companies intwo major metropolitan areas. Companies varied in sizefrom 20 to over 100,000 employees, and represented arange of industries, including financial services, insur-ance, business and consulting services, courier services,travel, media, utilities, and government services. Theobjective was to understand the practices followed andhow and why this form of software development mightdiffer from other forms.

We collected data through open-ended (semistruc-tured) interviewing and used grounded-theory method-ology to analyze it (Basics of Qualitative Research:Techniques and Procedures for Developing GroundedTheory, 2nd ed., A. Strauss and J. Corbin, SagePublications, 1998).This methodology, common in qual-itative research, uses a systematic set of procedures todevelop a theory or understanding that is inductivelyderived from the study of the phenomenon it represents.Because the method relies on systematic data collection

and analysis, which are tightly interwoven,researchers can obtain significant insightsinto the phenomenon and understand itmore deeply. Our analysis identified corecategories and their interrelationships,explaining how and why high-speed soft-ware development differs from traditionaldevelopment.The result was the identifica-

tion of the six development practices described in themain article.

Discovery colloquiumIn the second phase, we synthesized our phase-one

findings on best practices for achieving quality andagility in high-speed software development. For thisphase, we used search conference techniques in a dis-covery colloquium (Future Search:An Action Guide toFinding Common Ground in Organizations &Communities, 2nd ed., M. Weisbord and S. Janoff,Berrett-Koehler Publishers, 2000). Search conferencesproduce data analysis and findings coincidentally; thefindings serve as a conceptual foundation for the dis-covery colloquium.

This phase involved 35 participants, some of whomcame from the 10 companies; others we selected for theirexpertise on high-speed software development.Consequently, the participants represented a broad spec-trum of methodological perspectives—from agilemethodology adherents to those who embrace tradi-tional software process disciplines. Four breakout groupsworked through a process of identifying links, contra-dictions, and interdependencies among the identifiedpractices and problems. From this process, we derivedthe main problems that high-speed developers face.

Anatomy of an Empirical Study

July ❘ August 2006 IT Pro 31

logical innovations of market leaders. Traditional serialsoftware development is a luxury that can doom an organ-ization in first-to-market competition.

The practice of parallel development and frequentreleases faithfully and rapidly fulfills most market expec-tations. It is both responsive and adaptive, permitting therapid introduction of new features into software products.An organization can dynamically reprioritize require-ments according to current needs and delicately slip fea-tures that prove problematic without holding up othercritical functions. It is straightforward to remove softwaremodifications if unforeseen issues develop.

DrawbacksUsers can become confused when

frequent releases change features andfunctionality, which in turn requiresmore investment in user training.

Frequent releases might also stimulate impossible expec-tations: Customers grow to expect highly personalized sys-tems or rapid responses to requirements (the “I neededthis yesterday” syndrome). The practice also necessitateschunking requirements into small packages.

Another drawback is that large, complicated revisionsare nearly impossible to contemplate. The limited scope

Table 1. Six common problems in high-speed development and practices that companies use

Problem Favored practice

Demands of time-to-market compression Parallel development and frequent releases

Insufficient programmer productivity Greater reliance on tools and reusable components

Ambiguous requirements Production prototyping

Fluid requirements Customer implantation

Lack of design time and experience Mulitiered architecture and emphasis on acquiring the right expertise

Changing environment Tailored methodology

Get accessto individual IEEE Computer Society documents online.

More than 100,000 articles and conference papers available!

$9US per article for members

$19US for nonmembers

www.computer.org/publications/dlib

32 IT Pro July ❘ August 2006

I N T E R N E T S O F T W A R E

of requirements might lead to scalability problems. Forexample, many small components could introduce cou-pling and communications overhead that becomes over-whelming at high volume.

PRACTICE 2: TOOLS AND REUSABLE COMPONENTS

Using carefully chosen tools and component-based devel-opment can greatly speed design and coding. The infra-structure and tools that new technologies provide offer muchof the functionality that organizations once built into theirtraditional software development processes. In contrast,high-speed developers rarely craft software from scratch,preferring to assemble as much as possible from reusablecomponents. Tools automate the coding of many commonfunctions.Reuse is key,along with the know-how to acquire,integrate,and assemble components with wrappers and gluecode. Component reuse extends to all architectural levels:interfaces, business logic, back end, and so on.

Essentially, this practice implements a buy-versus-buildstrategy, in which the idea is to build software from toolsets rather than coding it from scratch.

AdvantagesIn addition to the direct savings

from reuse,development projects canuse developers with less experienceand skill. Visual development envi-

ronments do not require nearly as much familiarity withcomplex, underlying programming languages. The devel-opment environment might also provide an implicit archi-

tecture for the software product, suggesting that develop-ers might need less familiarity with the architecture’sdesign and development. As a result, development costscould drop and result in higher quality.

DrawbacksA dependence on tools and com-

ponents can become golden hand-cuffs. It is difficult to shift platformsor vendors when an entire software

suite has strong ties to a particular development architec-ture. Latent component quality issues can be costly toresolve at the final build. The cost of this dependence isparticularly high in an unstable market with rapidly chang-ing technology.

As an example of the messy mapping of practices andproblems we alluded to earlier, this practice also increasesprogrammer productivity, but at the cost of organiza-tional expertise. With automation comes an increasedreliance on less experienced programmers, and pro-grammers with experience in high-speed developmenttend to stick with known development environments.Together, these effects can degrade an organization’s pro-gramming expertise.

PRACTICE 3. PRODUCTION PROTOTYPING

Most software engineers accept that rapid prototypingcan improve customer-developer communication becauseit focuses attention on an operational artifact. Indeed, in1995, Frederick Brooks suggested prototyping as one of

As Frederick P. Brooks contended sofamously, no silver bullet will magically van-quish the monsters of software develop-ment: schedule and budget overruns, andpoor-quality products ( “No Silver Bullet:Essence and Accidents of SoftwareEngineering,” F.P. Brooks, Computer,Apr.1987, pp. 10-19). In the same article, hedescribes the essence of problems inherentin software and explains how many new technicaladvancements address accidental rather than essentialdifficulties. He described the essence of problems inher-ent in the nature of software: complexity, invisibility, con-formity, and changeability. Complexity of softwareproducts increases nonlinearly with size. Software prod-ucts cannot be visualized (have no reality in space), mustconform with existing institutions, and react to change.

Brooks explained how many technicaladvancements at that time eschewed essen-tial difficulties in favor of addressing acci-dental ones, which arise from the way weproduce software. The advancements ofthat time include high-level languages, time-sharing, object orientation, AI, and graph-ical programming. He also discussed fourpromising attacks: buy versus build, require-

ments refinement and rapid prototyping, incrementaldevelopment, and the use of great designers.

The six problems described in the main article corre-spond to Brooks’ “accidental difficulties” and the prac-tices we identified arise as intentional attacks on theseaccidental difficulties. However, some evidence indicatesthat the same practices provide partial solutions for soft-ware development’s essential difficulties as well.

Essential versus Accidental Software Difficulties

July ❘ August 2006 IT Pro 33

the most promising technological efforts (The MythicalMan Month: Essays on Software Engineering,AnniversaryEdition, Prentice-Hall, 1995), and his assessment hasproven correct. Design prototypes help finalize require-ments and design issues and are discarded after softwarebuild. Production prototypes are efficient enough to sup-port live operation. Component-based development isenabling the use of production prototyping to rapidlydevelop production systems.

AdvantagesPrototyping is well known for

resolving problems with unknownor poorly understood requirements.Such problems arise in high-speed

development because users often do not know exactlywhat they want. Because companies are often creatingproducts and services in markets that are too new to havedomain experts, no one fully understands the require-ments. Production prototyping crystallizes requirementsand reveals design issues, raising user involvement insoftware development. Customers can find such activeparticipation very rewarding. Not only is the user-

designed dialogue rich and focused, but the team alsoreaches the coding stage quickly. By the time develop-ers and customers have settled specification require-ments, they have often very nearly developed thesoftware.

DrawbacksBecause developers cannot rely on

a formal specification and are cap-turing requirements only informallyin feature lists and user stories, pro-

duction prototyping can be costly. It can involve a fairlylarge amount of rework in changing operational softwaresystems to match shifting customer demands. Prototypingcan also lead to a disproportionate focus on the user inter-face,giving short shrift to important computational aspects.Critical requirements like security, scalability, and robust-ness are hard to appraise through prototyping.

PRACTICE 4: CUSTOMER IMPLANTATION

High-speed development teams often enlist customersor users either full time or temporarily, assigning them as

By Donald J. ReiferReifer Consultants Inc.

This guide offers a step-by-step process for estimating software costs. Built on public-domain information and cost models, it gives the formulas software developers need to estimate the effort and time required to design, develop, test, and deliver their software projects. $19

www.computer.org/ReadyNotes

The Poor Person’s Guide to Estimating Software Development Costs

IEEE ReadyNotes

34 IT Pro July ❘ August 2006

part of the team, a practice known as customer implanta-tion.As developers construct the software from informallyspecified requirements and customer-developer discus-sions, customers prioritize requirements and redirectdevelopment, release-by-release.

AdvantagesHaving customers close by pro-

motes the refinement of require-ments as developers and usersinteract, which in turn improves

design decisions. Establishing detailed technical require-ments is one of the most difficult parts of software devel-opment. Because neither the developer nor the customerknows the answers (or sometimes even the questions), cus-tomer implantation creates a setting where developers andcustomers journey together through the shortened release-by-release development process.

Requirements refinement also helps counter the prob-lem of fluid requirements. Changing requirements arisein high-speed development not only because users areimprecise or unknowing, but also because the market-

place and technology are evolving.This turbulence oftenleads developers to avoid formally documenting require-ments, because they see such activity as unnecessary overhead. Detailed requirements analysis delays thedevelopment team’s response to rapidly changing mar-ket conditions.

Few techniques provide higher user satisfaction than cus-tomer implantation. The customer is privileged in thisdevelopment approach. Developers receive immediatefeedback on creative new features.The approach also rap-idly moves the latest customer needs into the system.As aresult, there is less risk that developers will build yester-day’s systems for tomorrow.

DrawbacksAs with prototyping, customer

implantation assumes that usersknow what they want, and that thisviewpoint is consistent across the cus-

tomer base. Unfortunately, this is rarely the case. Manycustomers or users do not think consistently and system-atically about their day-to-day problems. Even a singlecustomer participant is liable to level conflicting require-ments, unwittingly evincing an evolving view of his com-pany’s needs. Developers must routinely bound customerrequirements against the quality that the delivered prod-uct can achieve.

PRACTICE 5: MULTITIERED ARCHITECTURE

Organizations involved in high-speed developmentheavily use off-the-shelf components to rapidly developsoftware release-by-release, and they typically have a less than adequate understanding of the requirements.Adopting a stable, multitiered software architecture helpsanchor this volatile rapid development process, enablingeach release to be developed with some similarity and thegreatest degree of component reuse.The architecture canbe explicit or implicit. In the latter case, the developmentenvironment or component set might define the architec-ture. Many organizations adopt a simple three-tier archi-tecture: data storage, business logic, and user interface.Again, adoption tends toward buy instead of build.

AdvantagesThis practice partially compensates

for not having design time anddesigner experience, keeping thesoftware system from suffering a

poorly thought out design. It also reduces complexityby separating concerns. Such architectures usually help

ensure scalability. Data storage elements separated by thearchitecture are often easier to port to larger scale engines,and it is relatively easy to redevelop user interfaces foranother context.

I N T E R N E T S O F T W A R E

➤ “Is Internet-Speed Software DevelopmentDifferent?” R. Baskerville and colleagues,IEEE Software, vol. 20, no. 6, 2003, pp. 70-77.

➤ Extreme Programming Explained: EmbraceChange, K. Beck, Addison-Wesley, 2000.

➤ “Get Ready for Agile Methods, with Care,” B.Boehm, Computer, Jan. 2002, pp. 64-69.

➤ Competing on Internet Time: Lessons fromNetscape and Its Battle with Microsoft, M.Cusumano and D. Yoffie, Touchstone, 2000.

➤ “Software Development on Internet Time,” M.Cusumano and D.Yoffie, Computer, Oct. 1999,pp. 60-69.

➤ “Agile Modeling, Agile Software Development,and Extreme Programming: The State ofResearch,” J. Erickson, K. Lyytinen, and K.Siau, J. Database Management, Oct.-Dec. 2005,pp. 88-99.

➤ Adaptive Software Development, J. Highsmith,Dorset House, 1999.

➤ Rapid Development: Taming Wild SoftwareSchedules, S.C. McConnell, Microsoft Press,1996.

➤ Agile Software Development with SCRUM, K.Schwaber and M. Beedle, Prentice Hall, 2001.

Resources

July ❘ August 2006 IT Pro 35

DrawbacksIn the rush to deliver functional-

ity, developers can neglect detailedarchitectural design issues such asappropriately modularizing compo-

nents and optimal layering of application functions.Themost costly aspect of using a multitiered architecture isthe inevitable set of constraints it will place on softwaredesigns. Developers must be creative in making the software meet the requirements of both the problemdomain and the technical domain that the architectureconstrains.

PRACTICE 6: TAILORED METHODOLOGY

The processes and methods in high-speed developmentvary considerably according to project team and theproduct’s nature. Project teams sometimes tailor theirmethodologies daily. Pressured by intense demands forspeed, developers might skip phases or tasks that theysee as impeding their ability to deliver the software ontime.This practice exemplifies how high-speed develop-ment practices attack change. Developers imbue theirprocess with only enough structure to work effectively inan unstable environment.

In this practice, the organization tailors the develop-ment methodology as needed, including developmentprocesses, methods, and life cycles. Some organizationsdevelop each release with a slightly different (perhapsimproved) process, which lets them use high-speed soft-ware development to respond quickly to changes causedby markets, technology, and product requirements. Thisincremental and perpetual change is characteristic of thedevelopment organization itself and works against estab-lishing consistent, static processes. In this environment,stable development environments, tools, componentlibraries, or methodologies can easily fail because theeffort dedicated to process definition is often overturnedand thus wasted.

AdvantagesBy keeping the development

process fluid, high-speed develop-ment absorbs environmental changesmore easily. The software develop-

ment process adapts to the nature of both people and proj-ect.With bright, experienced teams, it is possible to bypassunnecessary work and avoid communication overhead.

DrawbacksDevelopment methodologies that

are constantly changing can lead tothrashing as developers spend moretime organizing the development

process and less time developing software.With less expe-

rienced teams, the communication overhead can be sig-nificant.Development teams working on different releaseswork on different process phases. Each follows a differentversion of the development process, leaving much oppor-tunity for confusion.This practice can come at the cost ofmuch less repeatability and consistency across develop-ment teams and project phases. A process with too muchfluidity could degenerate into no process at all.

AN EFFECTIVE SYMBIOSISAlthough little is new about these individual practices,

the demands of the high-speed environment have broughtthem together into a novel and powerful arrangement. Avariety of factors—the ability to quickly deploy newer ver-sions, parallel development, and the willingness to acceptlower quality at least in the early life cycle stages—con-tribute to the unconventional use of these conventionalpractices. Given that the pros or advantages of oneapproach can compensate for the cons or drawbacks ofanother, the collective use of such practices makes themfar more effective in a range of high-speed developmentenvironments than in the past.

Consider, for example, the much larger scale at whichdevelopers use prototyping, relative to conventional sys-tems development.A prototyping drawback is the inabil-ity to fully address concerns of security, scalability, androbustness. A multitiered architecture compensates forprototyping’s downside by offering improved scalabilityand the ability to manage complexity. In this way, long-

SUBSCRIBE NOW!www.computer.org/pervasive/subscribe.htm

IEEE Pervasive Computing delivers the latestdevelopments in pervasive, mobile, and ubiquitouscomputing. With content that’s accessible and usefultoday, the quarterly publication acts as a catalyst forrealizing the vision of pervasive computing.

36 IT Pro July ❘ August 2006

established techniques such as parallel developmentreceive a new boost when packaged with prototyping andcustomer implantation. In short, the pros and cons of eachpractice interlock and harmonize, creating a collective thatoperates quite satisfactorily in high-speed developmentenvironments.

Together these practices address time-to-market,a chang-ing environment, programmer and designer productivity,and fluid requirements. As such, participants in our studybelieve that they are shaping a new systems developmentculture—a set of shared attitudes, values, goals, and prac-tices. Indeed, in a high-speed development setting, culturalattitudes and values are also critical ingredients and aretypically present in organizations that embrace the six prac-tices. In such settings, smart people who act effectively withcourage and innovation are rewarded.

TOWARD A DEVELOPMENT FRAMEWORKData that link these practices to business performance

would be helpful to practitioners considering their adop-tion. However, as Michael Cusumano and colleagues sug-gest in reporting the results of their global softwaredevelopment practices survey, it is difficult to establish sucha link because performance varies dramatically from proj-ect to project (“Software Development Worldwide: TheState of the Practice,” M. Cusumano and colleagues, IEEESoftware, Nov.-Dec. 2003, pp. 2-8). Even without perform-

ance data, organizations continue to adopt this set of prac-tices.When a certain number of users have adopted a tech-nology, it has achieved critical mass, which influences itsfurther adoption.Undoubtedly, these six practices will con-tinue and perhaps become the roots of a framework fororganizations looking to establish a high-speed develop-ment process. ■

Richard Baskerville is a professor of computer informa-tion systems at Georgia State University. Contact him atbaskerville@gsu.edu.

Balasubramaniam Ramesh is a professor of computerinformation systems at Georgia State University. Contacthim at bramesh@gsu.edu.

Linda Levine is a senior member of the technical staff atCarnegie Mellon University’s Software Engineering Insti-tute. Contact her at ll@sei.cmu.edu

Jan Pries-Heje is an associate professor in the departmentof Design of Organizational IT at the IT University ofCopenhagen. Contact him at jph@itu.dk

For further information on this or any other computingtopic, visit our Digital Library at http://www.computer.org/publications/dlib.

I N T E R N E T S O F T W A R E

Learn how others are achieving systems and networks design anddevelopment that are dependable and secure to the desireddegree, without compromising performance.

This new journal provides original results in research, design, anddevelopment of dependable, secure computing methodologies,strategies, and systems including:

• Architecture for secure systems• Intrusion detection and error tolerance• Firewall and network technologies• Modeling and prediction• Emerging technologies

Publishing quarterlyMember rate: $31Institutional rate: $285

Learn more about this newpublication and become a subscriber today.

www.computer.org/tdsc

IEEE TRANSACTIONS ON DEPENDABLEAND SECURE COMPUTING