From the Editor
IEEE Software, May/June 2002
I Know What I Know
In most of my columns, I write about topics I know about.
I am becoming increasingly aware of how many topics I don't know. This
column describes some questions that I personally would most like to have
How Important Is Software Construction?
Software construction has been the awkward stepchild of
software engineering for decades. This puzzles me because software
construction is the only activity that's guaranteed to be done on every
project. Code is the center of the software universe. Process advocates tend
to downplay coding, focusing more on the documentation that occurs before
and after coding than the code itself. Academics have focused for decades on
eliminating coding. My efforts to recruit construction articles for IEEE
Software have been an uphill battle because it seems that very few people
want to write about coding.
Because construction happens on every project, why do
some experts downplay its importance? I suspect that a lot of the energy
behind two recent movementsopen source and Extreme Programmingarises because
each recognizes the central role that coding plays in software development.
This is a breath of fresh air to software developers who never forget that
software is code.
How do You Manage Multiple Releases?
Managing complicated versions is one of the most
significant challenges in software I see today. Released versions can vary
by features, hardware platform, language, culture, customer, and many other
factors. I commonly see companies actively supporting and enhancing more
versions of their system than they have programmers. What are the most
useful strategies for managing large numbers of concurrent releases based on
the same code base? What are the strategies for managing requirements,
design, and tests that go along with those releases?
Why Doesn't Everyone Use Revision Control Software?
A more mundane question I have about configuration
management is, Why are some people still not using revision control
software? Ten years ago I debated whether I should write about revision
control software in my book Code Complete. I assumed revision control
software was so common that discussing it would be passé. After talking with
literally hundreds of developers and managers the past several years,
however, I am convinced that somewhere between 10 and 50 percent of software
organizations still do not use revision control software. Why?
How Is Popular Software Designed?
I would like to see the designs for some of the world's
best known software. What does the design for the Sabre airline reservations
system look like? What about the
air traffic control software? What are the guiding principles of the design of
Windows 2000, PC-DOS, and IBM OS/360? What about the space shuttle flight
control software? What are Excel's major design challenges? What about SAP?
What about Amazon.com's Web site?
If these popular software products were buildings, I
would be able to see at least some of their designs. For example, the
National Archives and Records Administration Web site (www.nara.gov)
contains plans for 28,000 buildings going back 150 years. Architectural
techniques are not treated as "proprietary" because the public has a stake
in building safety. Software has become so pervasive in modern life that I
think the public has a similar interest in the design of some of the most
pervasive software systems. What would it take to see these designs?
How Big Are Popular Programs?
How big are today's common systems, and what did it take
to build them? I'd like to see cost, effort, schedule, lines of code, and
defect counts for major applications such as Windows 2000, TurboTax, Norton
Anti-Virus, Adobe PhotoShop, Excel, and SAP. Having a list of the management
parameters of well-known applications would help companies create meaningful
ballpark estimates for their own systems. It wouldn't replace detailed
estimation, but would help reduce the common factor-of-2 to factor-of-10
errors in initial ballpark estimates.
Why do Software Professionals Still Fall for Silver Bullets?
Fifteen years ago in his classic article "No Silver
Bullets," Fred Brooks predicted that no single tool or practice would
produce an order-of-magnitude improvement in quality or productivity over a
10-year period. In spite of repeated "silver bullet" claims for innovations
ranging from automatic programming to component-based development to
object-oriented programming to CASE tools (the list is nearly endless), no
single tool or practice has risen to the level Brooks described. Time has
proved Brooks' prediction correct.
Software professionals have been burned time and time
again by exaggerated claims for new tools and practices. My question is, Why
are so many smart, experienced software professionals stillso gullible about
Do Compensation Structures in Software Organizations Make Any Sense?
Many companies continue to treat managers as
hierarchically superior to technical staff and pay them more. The idea that
companies turn good programmers into bad managers is so common it is a
cliché. Software managers have a broad span of control, whereas technical
staff tend to be much more narrowly and deeply focused, and I think this
might be part of the reason why managers are paid more. But professional
athletic teams value depth of skill at least as much as breadth. Star
players earn more than star managers. Why don't software companies do the
Similarly, the ten-fold difference in productivity
between best and worst software developers has been well documented. Yet I
routinely talk to managers who say their companies will not pay above market
to attract top developers. Considering that the difference in compensation
between best and worst developers is only about 25 to 50 percent, while the
difference in performance is about 1,000 percent, why don't all companies
make at least some attempt to hire from the top of the talent pool?
How Good Are Most Software Companies?
In the software process area, the Software Engineering
Institute reports that organizational process maturity has increased
dramatically. In 1991, approximately 80 percent of organizations assessed
were at Capability Maturity Model Level 1. By 2001, only 38 percent of
organizations assessed were at CMM Level 1. My question is, How many
companies are really at CMM Level 1? Only a small number of companies report
assessment data to the SEI (less than 500 companies in 15 years). What are
the CMM levels of the thousands of companies that don't report their results
to the SEI? What about the companies that haven't heard of the CMM?
(Actually, I think I can guess the answer to this question!)
What Are Software's Real Best Practices?
Although software people sometimes have a tendency to
latch onto "one size fits all" solutions, I think most people realize that
different application domains call for different software development
approaches. It's natural and appropriate to use one set of tools and
practices to develop avionics software and a different set to develop video
Certain clusters of practices seem to work well within
particular domains. For embedded systems, phased, gated processes with lots
of up-front requirements work and design seem to work well. For software
products companies, code-focused development efforts that use highly
committed individuals, have a close working relationship with marketing, and
perform extensive independent testing are appropriate. For in-house business
systems, executive sponsorship, steady end-user involvement, moderate levels
of requirements documentation, and developer testing seem to be key. These
broad strokes are recognizable to people working in these areas.
My question here is, Can we map out the applicability of
these practices in detail? Are there some clusters of practices that
interact synergistically? If some practices do interact synergistically, are
they always synergistic, or only when used to develop certain kinds of
software? Are there practices that are best practices in some contexts and
worst practices in other contexts? Does any single practice constitute a
best practice in all areas?
What do You Know?
I know what I know, and now I'd like to hear what you
know! If you have thoughts about these questions, I'd love to hear from you
1. Frederick P. Brooks , "No Silver BulletsEssence and
Accidents of Software Engineering,"Computer, vol. 20, no. 4, ; Apr. 1987, ,
2. "Process Maturity Profile of the Software Community
2001 Year End Update," Software Engineering Measurement and Analysis Team,
Software Engineering Inst., pdf/2002mar. pdf;
Editor: Steve McConnell, Construx Software, 11820 Northup
Way, Suite E200, Bellevue, WA 98008.