Slashdot Mirror
Why Does Software Cost So Much?
Summary: An older collection of essays, some good, some bad, from one of the most respected names in the software management field. An interesting read, not least because of the amusement to be gained from how things have, and haven't, changed. Worth reading if you have the time, but not as essential as some of his other titles.
Check your sources. Tom DeMarco is an established industry figure who occupies that rarest of market niches - he's a management consultant/guru who has the respect of technical people. He's the co-author (with Tom Lister) of the classic "Peopleware" (which I suggest you rush out and read), and it's on the strength of that title that I read his work. I normally lack even the slightest interest in management titles, on the basis that Sturgeon's Law seems to be especially strict in that genre. For example, both my copies of "The 7 Habits of Highly Effective People" and "The Monk Who Sold His Ferrari" ended up in the bin. (If it helps, I have a library of about 5K books [mainly novels], and have only ever thrown out 4.)
What's this book about? This is a 1995 title, and as such is interesting for historical value. The blurb states:
"Drawing together several essays published previously, plus ten all-new papers never seen beyond his circle of colleagues, Tom DeMarco tackles a multitude of tough subjects and wrestles fresh insight out of them. Here's a compact, compelling edition of this acclaimed consultant's views of managing the software process."
What you get is 230 pages of essays or opinion pieces. There are 24 pieces, ranging from a couple of pages to a couple of dozen pages. A smattering of titles:
- Why does software cost so much?
- Management-aided software engineering
- Lean and mean
- If we did only one thing to improve...
- Software development: State of the art vs State of the practice
- Software productivity: The Covert Agenda
As the titles suggest, the focus is on software projects specifically, although much of the discussion re managing the effort could apply to many technical disciplines. All pieces which refer to surveys don't use numbers pulled from a hat, they use numbers pulled from the bibliography at the back.
Target audience It's a mix. Most of the pieces seem aimed at management, from team leader to project manager, but the discussion will be of interest to most programmers, especially those suffering from the Bad Management Blues, or who are thinking of taking a step sideways into a team lead role.
What's good? Quite a lot. This isn't a long book, and it's not going to revolutionize your life, but it makes for a decent couple of hours reading. The author can certainly write, with a chatty style obviously honed by a career based on presentations. All the pieces are easily digested, and usually contain a nugget of something interesting.
There are a few nice points in here re how and why you should manage your software project, but for me, the interesting thing about this older title is that it's a very different world he's talking about! For example, one piece, from 1989, talks about the difference between programmers working on identical tasks. They show nice charts and I was amazed to see PASCAL and BASIC in there. I expected to see COBOL of course, but the small size of the C wedge was shocking. Of course, there was no wedge for C++, let alone Java or Perl.
As with any older title, there are technological fossils like this to be marveled over in several essays, but it's quite interesting how the author pronouncements are generally, well, reasonable and right. He's not Nostradamus, and doesn't predict specifics, but there is a nice discussion on language uptake (he rails against FORTRAN and COBOL in a world of Modula-2, Oberon and SmallTalk! I suspect more people now now use the either of the former languages than all the latter languages put together). In this essay, he talks about how some of the third generation languages are wonderful, but suffer from inadequate or confusing libraries. He suggests that only wide and deep libraries really make people change languages in the real world. I know (from reading his new title, "Slack", review coming) that he's much further from the code now, but I wonder what he makes of Perl or Java? (Certainly the thing that lured me from C++ to Java was the libraries. Well, I missed the STL which makes the Collections API look like a child's homework.)
Other essays talk about the Microsoft anti-trust trial, or the fate of IBM. In both cases he seems to be more-or-less on the money, simply by being slightly cynical and not making any mad assumptions. Of course, by the same token, nothing he predicts is particularly startling, but still, of interest when reading.
There are a quite a few pages devoted to things which don't relate to technology specifically, and hence, don't appear dated now. These generally concern scheduling, or people management, and generally are as good as people expect this author to be. When he's good, he's very good. I want to work with a manager like him someday, just to see what it's like! However, even in these people-skills sections, I can't help but wonder what he'd revise in the light of the whole dot-con debacle.
What's bad? Well, this is a fix-up title, and some of the essays are, to be frank, crap. I doubt any but his most ardently completist fans want to read an essay on his experiences trying to work with desktop video for example. A couple of the essays just struck me as, well, rather pointless. Sometimes funny, but pointless. These tended to be the "Not previously published" ones, and I think there's a reason for that.
Alternate titles Oh, sure. There's a shelf full of titles like this in your nearest bookshop. I don't generally like any of them though, so I'll just recommend his earlier Peopleware and his latest, Slack.
You can purchase Why Does Software Cost So Much? from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Coding is just like creating art. :).
Some art is cheap, some artist give their art away for free (i.e. on subways
THAT is why (some) software is expensive.....
1) Marketing and advertising
2) Paying for management's perks (think: Bill Gate's massive house, and the Oracle guy's Americas' Cup challenge.
And for those who can spare a few pennies for a distro, there is always CheapBytes.
But the author does have an interesting point. Kind of like the question: Why did someone pay me $1010 USD for the Eaglehorn bow a week after the Diablo II xpack was released? ;)
This is all just proof positive that the real wealth resides in the human mind, not in a few flipping bits.
"To confine our attention to terrestrial matters would be to limit the human spirit." -Stephen Hawking
Software actually doesn't cost a whole lot at all. Think about it. Most companies have only one flagship product. Let's look at Alias|Wavefront, the makers of 3d Giant- Maya. Maya has a base price of $2,000.
3D graphics is a niche market--this means low numbers of sales. Couple that with the fact that there is apparently a number of working cracks and keygens spread out across the internet, and you're looking at seriously low sales.
Now, at the surface, $2,000 is a lot of money. It's 10 of those Walmart-Lindows computers... It's one mid-to-high range PC.
Look at it from A|W's point of view, though. $2,000--if you're paying one programmer a paltry sum of $10/hour (which we all know the best programmers won't accept), that's only 200 man-hours. Now, you need a staff of programmers, accountants, secretaries.. You need to pay your IT people, your connectivity bills, rent on offices, advertising costs, etc.
Cost-of-development far outweighs cost-of-software. The golden days of companies becoming rich off of software is over, even heavyweights like Microsoft are cutting back.
Yeah, software is still expensive for a consumer... But think of how expensive it is to *develop* that software.
-Sara
Really, the effect of "piracy" (aka widespread copyright infringement) is to retard the developement of Free Software/Open Source solutions. People everywhere have an instinctive feeling that if a product has no physical form, and the per-unit cost of duplication is zero, they should be able to reproduce it at will. If not for extensive copyright laws, they could do so, without having to renogitate the publisher's permission each time.
Since those laws are often ignored, many people get away with behaving like that, even though its illegal. (Home consumers do this all the time. Corporate folks do it on a smaller basis, and try not to leave machines permantently running such code, but often pass through transitional periods of |installed copies| > |paid licenses|.)
If it were harder to "pirate", then the user base would satisfy their need for free copies with "Free" software, and we'd all be better off.
I am a developer. In fact, I being the only developer on this project. I have two project managers that I report to, and the clients. Doing the daily status reports, the weekly status report, the monthly status report, the half-day meetings several times each week, the countless hours I spend backing out stupid ideas the client came up with that my two managers were too brain-dead to say no to,....
Well, you are getting the idea. The actual coding going into this effort is going to be worth about $10000 but our accounting says the client is going to have to pay $125000 for us to not lose money. That is being one hell of an overhead, folks. All that money to train managers, wasted.
Why do companies develop TWO versions of a program (one lite/crappy, a la MS Works and one high end/professional version a la MS Office) and then sell the high end for several hundred dollars and the lite version for under $100?
You'd think that the cost of developing two separate versions would outweigh the benefits of having the "professional" version available to everyone, at reduced price to reflect the economies of scale that come in to selling to a broader market.
Spending EXTRA money to develop a crappy version of your software that you can sell to millions of people for cheap, just to protect the giant inflated prices of the high end stuff that you might only sell a few thousand licenses of, just doesn't make any sense.
Why not just sell the full version to EVERYONE and reap the benefits of economies of scale? Customers get better product, cheaper, you get more customers and more revenue. Everyone wins.
You see? You see? Your stupid minds! Stupid! Stupid!
What exactly is going to pay my bills if I don't have a job?
While you seem to despise capitalism. What I picture when I read your post is everyone on the government payroll getting assistance. What I also picture is absolutley no personal freedom whatsoever, everyone would be serfs to the government king. Thanks, but no I think I pass on capitalism dying right now.
Society is not advanced enough to get past capitalism without reverting to a fuedal lord type of system. Now, when you have near limitless energy generation, coupled with replication devices for everyone, you can have the Star Trek utopia you are probably hoping for.
As an example, there's a small, general "technology" company is S. E. Michigan that faxes large technical drawings to India, where the cheap but educated labor produces electronic copies in various CAD packages. The involved telecom & foreign labor costs are a fraction of what it would cost to have the drawings produced state-side.
And we've all read the articles on how technical support centers are largely out-sorced abroad.
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
The master programmer shrugged. ``Then the design will never be completed,'' he said.
---
A manager asked a programmer how long it would take him to finish the program on which he was working. ``It will be finished tomorrow,'' the programmer promptly replied.
``I think you are being unrealistic,'' said the manager, ``Truthfully, how long will it take?''
The programmer thought for a moment. ``I have some features that I wish to add. This will take at least two weeks,'' he finally said.
``Even that is too much to expect,'' insisted the manager, ``I will be satisfied if you simply tell me when the program is complete.''
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
must... stay... awake...
You don't much about industry, do you?
If there was a 1/4" gap on a door panel, water would flow.
When you buy a car, probaly about 15% of it is raw materials. about 35% of it is employee health insurance.
I don't have an auto industry example, but here's one from the steel industry:
Korean steel companies require about 16-25 workers to do the job of 2 workers for US Steel. It costs them about 2.5x more to produce a given quanity of steel than a good US mill.
Why are American steel companies bankrupt then? Health care costs for pensioners accound for $0.35 for every dollar of revenue.
The Software industry has no unions, few retirees. Software is cheap because they lack the overhead of industrial companies. Plus additional copies of software cost nearly nothing make.
Conformity is the jailer of freedom and enemy of growth. -JFK
- Distributed systems are fundamentally hard
- Design is fundamentally hard
- Difficulty organizing large teams
- Use of bad or ad-hoc development processes
- Conflicts between developer and management objectives
My take is that for any easy problem, the software is written once, standardized, and doesn't need to be changed. You only need to write new software to deal with the problems or environments you didn't anticipate before, which is inherently unpredictable.