Sighs Heave for "Last Gasp"

Readers react to Alan Cooper's Software Architect column, "The Last Gasp, " even asserting that Alan "must be living on another planet."

• By Readers of Visual Studio Magazine
• 01/01/2004

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Sighs Heave for "Last Gasp"
Alan Cooper's viewpoints have merit [The Software Architect, "The Last Gasp," November 2003]. However, the thundering sound you hear is the "Old/New" Economy rushing to send its software development jobs overseas to places like India where they can reduce their "variable" costs by hiring developers at $1.50/hour.

Even though I agree with Alan on a philosophical level, the cardinal rule is that capital will always flow to the place of greatest return. And it makes no difference whether you're making software or motherboards.

Stevyn R. Dembo, Delta, British Columbia, Canada

As a businessman and mechanical, electrical, and software engineer who has spent the last 23 years in the software industry, I can say Alan Cooper's The Software Architect column, "The Last Gasp," is the most irresponsible and priceless piece of magazine filler yet. Mr. Cooper must be living on another planet or have no experience in calculating the costs of software development, and he certainly has never developed a project that required conventional funding to complete.

Software is a manufactured good. This finished product is delivered via a communications link or on a physical disk or CD. Both of these methods require energy, infrastructure, and various other means of human and mechanical support. Developing software also requires the "tools" of the trade, which I spend about $7,000 to $10,000 on annually to maintain. Unlike a mechanic's tools, a software mechanic's tools must be replaced every year. Over a 10-year period, I have spent more than $75,000 in upgrades and maintenance fees. Can you imagine going to the hardware store and purchasing a wrench, then throwing it out the next year and purchasing it again because the pipe fittings have changed? Business practices that would be unheard of in other industries are acceptable in the software industry because no one knows how to calculate development costs, assign product values, and provide hard numbers on the development process.

When software was developed internally as a support of the business, it was considered an "administrative cost." With the PC being made available to the general public over the last 20 years and the availability of commercial software, it is now a manufactured good. Software is the only manufactured good that has 100 percent of the development effort completed before a revenue stream starts.

I came from the machine tool industry, and we would routinely take three to four years to develop or redevelop products. Along the way, we would have customer focus groups and pre-sales units sent to the field for trials. A value for the end product could be calculated using several methods that allowed banks and other financial institutions to play a role in the support of the development effort. In 20 years, the software industry still has not reached a professional level in quality or in its focus.

When I shifted careers to start writing Radio Shack products, I believed the software industry would mature into the "iron horse" of the 21st century. Instead, it has fragmented more and more over the years, and little or no effort has been made to educate the general public of its value or the amount of work needed to develop new products. Bankers don't support software companies, and venture capitalists have no way of knowing which person is knowledgeable and which is a fraud.

Thanks to articles such as this one, it would appear that no investment is needed in making software, no energy is required, little knowledge is required, and development expenses are minimal. In other words, software has no value. If you want to write something useful, then why don't you do yourselves and the industry a favor and provide articles on how to calculate the real cost of software development, how to get traditional funding institutions to assist, and how to determine the best marketing channel? Most of all, why don't you write responsibly and think about the impact your words have on people who might not be familiar with the industry? If you need assistance in figuring out these topics, I'm sure the old-timers who came from other industries can help you out.

Oliver Bailey, McHenry, Ill.

I read Alan Cooper's recent The Software Architect column and found it an interesting, if not enlightening, read. Alan nearly had me convinced until I read his bio at the end: "... he has spent a decade making high-tech products easier to use and less expensive to build ... ."

It seems that even with this insight, perhaps things still get lost in translation. "Easier to use" was directly relevant to the article, as that would be a way to increase profits. "Less expensive to build" seemed contradictory. Did the article not state that perhaps more should be spent on development so that profitability can increase?

Perhaps the analogy should state that developers are like factory workers rather than the factory. As workers, our individual pay is fixed, but the overall pay for the workers as a whole can be variable. Take, for example, the number of contract developers in the market right now. A company needing to shorten its development time can hire contract programmers to give a boost to the current development team. This makes the total cost of development a variable factor rather than fixed, as these contractors can be added or removed on short notice.

I agree that this is a new economy and business as a whole probably doesn't fully know how to deal with it. Perhaps one day a brand-new business accounting model will be born to match the new direction of business.

Patrick Magill

Thanks very much for your interesting, but not enlightening, comments.

It is my observation that when software construction projects are planned properly, they take significantly less time and money to build. If you have detected what appears to be contrary evidence, I suggest that what you saw was a failure to plan properly.

Regarding your suggestion for hiring contractors, I refer you to Frederick Brooks' definitive-and-deservedly-famous-for-30-years essay, "The Mythical Man-Month," in which he asserts, and remains as-yet unchallenged, that adding programmers slows any software construction process. —A.C.

Create Multiple Threads With Caution
I found Bill Wagner's Desktop Developer column, "Optimize Multithreaded Apps" [October 2003], to be informative—perhaps in unintentional ways. For instance, clicking "start" after "pause" upset the thing:

if (PrimeCalcThread.ThreadState == 
   ThreadState.Suspended)

(in buttonStartPrimes_Click) doesn't work, because a watch window shows the informative "34" (.NET 1.1.4322) instead of "Suspended." Closing the program after clicking "pause" makes it unhappy for similar reasons—the command-line version seems to close but actually continues to lurk in memory until you kill it, and it won't finish in the IDE unless you click on "stop debugging."

Then it occurred to me, why would you try to improve performance with threads in .NET? If you were interested in performance, you wouldn't use .NET, would you? You'd use native code. To put it another way, do you think Microsoft is going to write the next version of Office in .NET?

There are functional reasons one might use threads—maybe to carry on some complicated background task, the kind of thing people do with state machines. But my guess is these are rare, and consequently Microsoft is unlikely to expend heroic efforts fixing .NET threads. So Wagner's sage advice—"if you don't have a compelling reason to create multiple threads, don't do it"—seems all the more apt.

J.G. Owen, Huntington Station, N.Y.

Well, there are really two questions. The first involves the problems you have found. Quite simply, it's my bug. The ThreadState enumeration is a bitfield, and I should have used the & operator instead of testing equality:

if ((PrimeCalcThread.ThreadState & 
   ThreadState.Suspended) != )

The case you mention indicates that the ThreadState is Suspended|WaitSleepJoin. My test did not find that. I simply did not catch that in my testing.

The second is more complicated. There are many levels of performance. While I agree that native code is faster than managed code, the difference is slight for well-optimized managed applications. I generally split my performance tuning into three distinct tiers. The first tier involves design and course optimization: Minimize database trips and avoid retrieving unnecessary data on database trips. The second tier involves the types of idioms I mentioned in the article: Minimize the communication between different components of the system, especially if threads and synchronization are involved. Only the final tier involves "heroic" efforts, as you describe. There is a continuum from "way too slow" through "fast enough" to "as fast as possible." You need to place your application on the right location on that continuum, based on the effort needed and your application's requirements. I've found that .NET provides a great means to being more productive and creating applications that are fast enough.

As for the comment that Microsoft won't write the next version of Office in .NET, I suspect the time when Office runs as a managed application has far more to do with the size of the applications than any performance concerns. The amount of work to move from existing code to .NET must be balanced against other feature requirements and release schedules. —B.W.