what do software developers need to know about busines
TRANSCRIPT
0 7 4 0 - 7 4 5 9 / 0 5 / $ 2 0 . 0 0 © 2 0 0 5 I E E E S e p t e m b e r / O c t o b e r 2 0 0 5 I E E E S O F T W A R E 5
from the editor
Arecent discussion I had with colleaguesfrom my university’s business schooland computer science department fo-cused on identifying the most criticalknowledge for software developers.My computer science colleagues’ per-
spective was quite interesting. They acknowl-edged that once a software developer has man-
aged to climb into a second- orthird-level management posi-tion, maybe an MBA wouldn’tbe such a bad idea. But for themost part, they held the strongbelief that anyone smart enoughto be a computer science gradu-ate must be able to easily pickup this “business stuff” on theside.
Type a or type b?I felt the same quick surge of irritation that I
usually get when dealing with students who wantto bypass prerequisite courses and enroll directlyinto an upper-division software engineeringcourse. They seem to think that software engi-neering can’t be all that difficult compared to themysteries of homomorphisms and context-freegrammars. It’s either (a) the height of conceit or(b) the height of ignorance about the depth of thefield to suggest that, without serious study, some-one could pick up a field that has taken othersyears to master. Over the years, I’ve come to re-alize that (b) is more common than (a).
So, whenever I hear someone talk about ei-ther business or computing issues as things to be“picked up on the job,” I can’t help but wonderwhether the person is “type a” or “type b.”That’s not to say that someone can’t learn ma-terial from either discipline through self-study—but it requires a serious application ofdiscipline and effort.
Understanding the contextI’m less concerned about those who have
chosen to pursue a management career path.Over time, I’ve come to believe there’s a realneed for the average software developer to un-derstand and appreciate the economic contextin which their company operates.
Without a thorough understanding of thebusiness context, we tend to operate in a fog,believing things happen arbitrarily by chanceand can’t be predicted. Primitive cultures’ lackof understanding of physical phenomena led toa belief that people became ill, soldiers won orlost battles, and storms devastated villages be-cause of angry “gods.” Individuals felt a loss ofcontrol over their daily lives and resorted to il-logical attempts to placate these “gods”through sacrifice and the construction of grandtemples.
I’ve observed developers’ bitter resentmentwhen they try to come to grips with seniormanagement’s seemingly illogical decisions andactions. Often, as in ancient mythology, theyattribute these actions to angry “gods” who ar-
What Do Software Developers Need to Know about Business?
Warren Harrison
E d i t o r i n C h i e f ■ Wa r r e n H a r r i s o n ■ P o r t l a n d S t a t e U n i v. ■ w a r r e n . h a r r i s o n @ c o m p u t e r. o r g
6 I E E E S O F T W A R E w w w. c o m p u t e r. o r g / s o f t w a r e
FROM THE EDITOR
bitrarily cancel projects, cut staff, andenforce technical mandates.
The fact is, modern, multinationalbusinesses operate within a set of well-understood phenomena. If you don’t un-derstand discounted cash flow, hurdlerate, or amortization of intangibles,many management decisions inflicted onyou might appear to be mere rolls of thedice or the wrath of angry “gods.” Hereare a few principles that can help putmanagement decisions into a clearercontext.
An investment is simply an investmentMany professions require a certain
amount of detachment from events.For example, scientists are renownedfor their ability to unemotionally viewand record phenomena that wouldhave lay people running for cover. Thejournalist’s credo is to never get per-sonally involved with the story. Policeofficers quickly learn to detach them-selves emotionally from grisly murdersand deadly traffic accidents.
If I had to put my finger on the sin-gle thing of most value that I receivedfrom my years studying for an account-ing degree, it would be the ability toview investments as just that—invest-ments. Nowhere is this better exempli-fied than in the concept of sunk costthat’s mercilessly hammered into cost-accounting students. This might be thehardest concept for laypeople to under-stand. “But we’ve already invested somuch money into this project” is acommon lament among software devel-opers when they hear that their projecthas been cut.
From the savvy business person’s per-spective, costs that have been expendedin the past have no role in planning forcosts in the future.
Tomorrow’s dollar is worth (far) lessthan today’s
Most of us are vaguely aware thatgetting money now is better than havingto wait for it, but we seldom go to thetrouble of quantifying exactly howmuch better. Business runs on the con-cept of quantified present value—thevalue of a sum received in the future,measured in “today’s dollars.” We can
even factor in risk premiums to reflectthe investment’s risks and opportunitycosts.
Most business people I know think interms of risk-adjusted present value. As aresult, long-term initiatives with evenmoderately uncertain payoffs quicklylose their attractiveness. This is espe-cially true when other investment oppor-tunities exist.
Capital budgetingI’ve endured more than one meeting
in which technical people propose proj-ects with seemingly no clue that themoney spent developing a softwareproduct could just as easily be investedin a bank, gold bullion, or opening aKentucky Fried Chicken franchise. Youcan usually identify these naive champi-ons right away: they’re the ones with alaundry list of poorly quantified, intan-gible “benefits” that will accrue if onlymanagement would open that squeakypurse and toss out a few million.
Of course, these unfortunate soulsusually try to dress up their presenta-tions with “business speak.” I onceheard someone speak glowingly of theROI expected from a project he wasproposing. It quickly became clear thathe didn’t understand what ROI stoodfor when his slides started displayingROI figures in terms of months. Itturned out that he had simply pluggedsome numbers into a textbook equationwithout understanding what he was do-ing. Subsequently, he and his team wereaghast when the tight-fisted spawn ofEbenezer Scrooge turned down the proposal.
If you don’t know what your com-pany’s hurdle rate is (or worse yet, ifyou don’t know what a hurdle rate is),do your homework before you makeyour pitch to the suits. At the very least,you’ll impress the decision makers. Atthe very worst, you’ll avoid making afool of yourself proposing a projectthat will take two years to yield thesame returns you can get at the localSavings and Loan.
Oh, and don’t forget, ROI standsfor return on investment, which is notthe same thing as IRR (internal rate ofreturn) or payback period.
Editorial: All submissions are subject to editing for clarity,style, and space. Unless otherwise stated, bylined articlesand departments, as well as product and service descrip-tions, reflect the author’s or firm’s opinion. Inclusion inIEEE Software does not necessarily constitute endorsementby the IEEE or the IEEE Computer Society.
To Submit: Access the IEEE Computer Society’s Web-based system, Manuscript Central, at http://cs-ieee.manuscriptcentral.com/index.html. Be sure to select theright manuscript type when submitting. Articles must beoriginal and not exceed 5,400 words including figures andtables, which count for 200 words each.
DEPARTMENT EDITORS
Bookshelf: Warren Keuffel, [email protected]
Design: Martin Fowler,[email protected]
Loyal Opposition: Robert Glass, [email protected]
Open Source: Christof Ebert, [email protected]
Quality Time: Nancy Eickelmann, [email protected],
and Jane Hayes, [email protected]
Requirements: Neil Maiden,[email protected]
Tools of the Trade: Diomidis Spinellis,[email protected]
STAFF
Senior Lead Editor Dale C. Strok
Group Managing EditorCrystal Shif
Senior EditorsShani Murray, Dennis Taylor, Linda World
Staff Editor Editorial AssistantsRita Scanlan Brooke Miner and Molly Mraz
Magazine AssistantHilda Hosillos, [email protected]
Art DirectorToni Van Buskirk
Technical IllustratorAlex Torres
Production ArtistCarmen Flores-Garvey
Executive DirectorDavid Hennage
PublisherAngela Burgess
Associate PublisherDick Price
Membership/Circulation Marketing ManagerGeorgann Carter
Business Development ManagerSandra Brown
Senior Production CoordinatorMarian Anderson
CONTRIBUTING EDITORS
Robert Glass, Keri Schreiner
S e p t e m b e r / O c t o b e r 2 0 0 5 I E E E S O F T W A R E 7
FROM THE EDITOR
So what can we do about it?Many years ago, when I was in grad-
uate school (1978–1984), it seemed thatone person could know a little bit aboutalmost every aspect of computer science.The body of knowledge was simply thatsmall. Nowadays, with more and moresubfields sprouting up, it’s hard for stu-dents to know even what all the areasare, much less a little bit about each one.So, it’s difficult to justify a large numberof nontechnical courses simply to “gaincontext.” Luckily, software developerscan get by with far less—after all, theidea is to establish a context, not to turnout investment analysts.
Several years ago, Bruce Schafer(founder of PC-Kwik, for you old-timers)and I put together a course for the Ore-gon Master of Software Engineeringprogram called “Understanding the Soft-ware Business.” This class undertookthe Herculean task of introducing stu-dents to the marketing, financial, andlegal aspects of the software industry in10 weeks. It involved general pricingstrategies, basic macroeconomic con-cepts, capital budgeting issues, and in-tellectual property.
We found that students (all profes-sional software developers with several
years of experience) came into the classwith a lack of exposure to economicand financial topics, a misunderstand-ing of the concepts of time value ofmoney, and little knowledge of pricingstrategies.
Although such a class clearly can’tturn students into experts in any of theseareas, it can provide them with the toolsto better understand the business aspectsof developing software and how deci-sions are made at the executive levels oftheir organizations. Such a course can goa long way toward preparing studentsfor a career in software development andis likely to be far more valuable thanmany of the traditional undergraduaterequirements such as differential equa-tions, linear algebra, or physics.
Feedback welcomeWhat do you think? Have you had
any experiences dealing with executive-level management at work? Do youfind that your company uses formalcapital-budgeting techniques in evalu-ating projects? If you have training inbusiness, economics, or finance, haveyou found that it has benefited you inyour role as a developer? Please write meat [email protected].
EDITOR IN CHIEF
Warren Harrison10662 Los Vaqueros Circle
Los Alamitos, CA [email protected]
EDITOR IN CHIEF EMERITUS:Steve McConnell, Construx Software
ASSOCIATE EDITORS IN CHIEF
Education and Training: Don Bagert, Rose-HulmanInst. of Technology; [email protected]
Design: Philippe Kruchten, University of British Columbia; [email protected]
Requirements: Roel Wieringa, University of Twente;[email protected]
Management: Don Reifer, Reifer Consultants;[email protected]
Quality: Stan Rifkin, Master Systems; [email protected]
Experience Reports: Wolfgang Strigel,QA Labs; [email protected]
EDITORIAL BOARD
Christof Ebert, AlcatelNancy Eickelmann, Motorola Labs
Martin Fowler, ThoughtWorksJane Hayes, University of Kentucky
Warren Keuffel, independent consultantNeil Maiden, City University, LondonDiomidis Spinellis, Athens Univ. of
Economics and BusinessRichard H. Thayer, Calif. State Univ. SacramentoRebecca Wirfs-Brock, Wirfs-Brock Associates
ADVISORY BOARD
Stephen Mellor, Mentor Graphics (chair) Maarten Boasson, Quaerendo Invenietis
Robert Cochran, Catalyst SoftwareAnnie Kuntzmann-Combelles, Q-Labs
David Dorenbos, Motorola LabsJuliana Herbert, ESICenter UNISINOS
Dehua Ju, ASTI ShanghaiGargi Keeni, Tata Consultancy Services
Karen Mackey, Cisco SystemsTomoo Matsubara, Matsubara Consulting
Dorothy McKinney, Lockheed Martin Space SystemsBret Michael, Naval Postgraduate School
Susan Mickel, Lockheed MartinAnn Miller, University of Missouri, Rolla
Deependra Moitra, Infosys Technologies, IndiaMelissa Murphy, Sandia National LaboratoriesSuzanne Robertson, Atlantic Systems GuildGrant Rule, Software Measurement Services
Girish Seshagiri, Advanced Information ServicesMartyn Thomas, Praxis
Rob Thomsett, The Thomsett CompanyLaurence Tratt, King’s College London
Jeffrey Voas, SAICJohn Vu, The Boeing Company
Simon Wright, SymTech
CS PUBLICATIONS BOARD
Michael R. Williams (chair), Michael R. Blaha, Mark Christensen, Roger U. Fujii, Sorel Reisman,
John Rokne, Bill Schilit, Linda Shafer, Steven L. Tanimoto, Anand Tripathi
MAGAZINE OPERATIONS COMMITTEE
Bill Schilit (chair), Jean Bacon, Pradip Bose, Doris L. Carver, Norman Chonacky,
George Cybenko, John C. Dill, Frank E. Ferrante,Robert E. Filman, Forouzan Golshani,
David Alan Grier, Rajesh Gupta, Warren Harrison,James Hendler, M. Satyanarayanan
Software engineering is a decision-intensive discipline. Can we build modelsthat make explicit the knowledge hidden in software resources? Can weuse models to make better decisions? Can we assess those models? Dodifferent researchers working on the same data arrive at similar models?Are there better, faster, cheaper ways to build software engineering models?
Many predictor models already exist but information about them is proprietary, so model calibration in different development environments isdifficult. This issue will look at how to build predictor models and whatwe’ve learned from open source data sets.
Visit our Editorial Calendar atwww.computer.org/software/edcal.htm
Next Issue Predictor Models in Software Engineering