Communications of the ACM
Forum
Forum
I especially liked Phillip Armour's idea of viewing projects through the lens of knowledge acquisition ("The Business of Software," Nov. 2002).
I work for a European pharmaceutical wholesaler and retailer, currently dealing with the first stages of a project to replace wholesale supply chain systems across Europe in conjunction with a large consulting firm. Though we started late, following extensive negotiations with the consultants, the end date was not pushed back. Meanwhile, we found only limited organized knowledge about the various systems, some of which have been evolving over a long time. The project has, however, already benefited the owners of these systems by giving them for the first time a single document with an overview of system functionality.
We have been told on occasion that nobody really knows what these systems do, as they have been modified extensively with little consistent documentation. I worry now that we are expected to determine future functionality, even though the existing systems, as well as business needs, are so poorly understood.
We will likely take a portfolio approach, though the main logistics system will be a package. The implication is that functionality will be based not on our knowledge of our processes but on the knowledge of some third-party software developers of generic logistics processes. The software-selection process will likely be based on a set of functional and nonfunctional requirements and used to determine whether each software product is close to some ideal for some particular need.
Perhaps we ought to be evaluating whether the developers' knowledge and understanding of the business processes the software is supposed to support actually match ours.
Simon Bennett
North Shields, UK
I want to thank Armour for an excellent column. I have been trying to get this message across to my management for years. Not only do they confuse the estimated cost and completion date with commitments, they enter into fixed-price agreements with our clients based on these sameestimates.
Lesley Clark
San Diego, CA
I enjoyed Armour's column, but the Strategic Defense Initiative (SDI) is a poor example of end dates. Historically, no missile shield has stayed ahead of penetration technology. Recall the 1990s Patriot system against the 1970s technology Scuds when the senior Bush tangled with Iraq. SDI is a perpetual development program with no foreseeable completion date. I'm not saying SDI is a bad idea. As a research project, it will almost certainly pay dividends. But it has no end date, unless you consider the end to mean that within 100 years it may be completely effective against the missiles of today.
Dan Klarmann
St. Louis, MO
Complex, But Not That Complex
In his "Practical Programmer" column ("Sorting Out Software Complexity," Nov. 2002), Robert Glass reported that "for every 25% increase in problem complexity, there is a 100% increase in complexity of the software solution," meaning "the difficulty of solving a problem in software grows exponentially." This statement is wrong. The stated relation corresponds to a polynomial of degree log(2)/log(1.25), so it is not as bad as presented.
Exponential complexity would correspond to a statement like "for every increase by some constant, there is a 100% increase in complexity of the software solution." If this were the case, we would have noticed it long ago, as it would have prevented us from developing any reasonable software at all.
Gernot Salzer
Vienna, Austria
I wholeheartedly agree with Glass's claims. Even a simple task (such as migrating from one version to another) is frequently difficult and time-consuming. The estimates for migration usually cover just the physical act of recording to accommodate the new versions; often lost is the effect it might have on OS versions, toolkit versions, libraries, and other apps running in the same space. Accounting for these factors is usually regarded by "clients" as unnecessary because they say they are prepared. Well, usually they aren't.
This is just my opinion, but it's based on years in both software systems and the physical sciences. The most important issue in dealing with the complexity of software systems is that most developers, engineers, and architects focus on only a small portion of the problem domain. Stepping back and viewing the solution in the larger context increases the probability of success. But it also usually means a longer time to deployment because we identify many more issues than just those in the immediate application.
Dan Hestand
Waltham, MA
Blame the Process, Not the Parties
Florida isn't solidly Republican but a mix of Democrat, Republican, Reform, Green, and I'm not sure what else. Each county runs its own voting organization through its own bureaucracy, employing its own methods for conducting an election. No two counties are alike; the staff of one can be technical wizards, while the adjoining ones are clueless.
Political preference isn't a marker for technical ability; the poorly programmed Florida machines could as easily have miscounted Democrat, Green, Reform, or all votes, thus invalidating the results in all races, including any candidate and referendum.
I was an election judge last Nov. 5 in a Texas county that misprogrammed its voting machines. If you voted a straight party ticketfor any partyyour votes were not properly applied. It was a bone-headed mistake by the election staff, forgetting to verify that party-line voting worked correctly; this simple mistake was found by a technician troubleshooting a failed voting machine.
It's difficult getting people to volunteer for Election Day duty; it's boring work. In my county, the Democrats and the Republicans normally trade clerks between precincts; volunteers may be asked to help the other party in different precincts as needed. That Florida should have the same problem isn't surprising or unusual. It's a feature of the volunteer nature of the U.S. election process.
None of the errors cited by Rebecca Mercuri in her "Inside Risks" column ("Florida 2002:Sluggish System, Vanishing Votes," Nov. 2002) can be laid at the doorstep of any party; blame lies in the speed new technology was introduced into a system that didn't realize how profound the changes would be and had no time to become fully aware of the limitations and quirks of the machines. The matter of the Sequoia machines being sold on condition that no details of their operation be revealed has nothing to do with politicsexcept inside Sequoia Corp.
Any industry or business adopting a new method of operation experiences a learning curvethe process of understanding why an error happened and remembering never to cause it again. Florida, embarrassed by the mistakes of the 2000 election, chose to completely change its election counting process. That the next election was a sorry mess shouldn't have surprised anyone; no great project ever began perfectly.
Richard Molpus
Dallas, TX
Mercuri Responds:
Richard Molpus makes an erroneous assumption that I was somehow blaming "Republicans" for Florida's election system problems. The word "Republican" was used exactly once in my column, in a factual connection to the misprogramming of optical ballot scanning data. It was not intended as a slur against a particular party. In the Boca Raton case I mentioned, Danciu is a Republican. I intended to make the point that all parties are equally at risk of having election data mishandled by unauditable voting systems.
The misprogramming of the Texas straight-party tickets was not, as Mr. Molpus asserts, "a bone-headed mistake" but a result of the complete lack of regulation and control of the auditing and testing of voting systems in the U.S. Despite the $4 billion now authorized by the Help America Vote Act, there is still no mandate that voting systems be examined in a methodical way to eliminate such errors. With the proliferation of unauditable and trade-secret-protected voting systems, such mistakes are more difficult to find (except in the most flagrant cases, where huge numbers of votes are somehow "missing") and more difficult to prevent.
I do not accept that "adaptation and training" or "understanding the limitations and quirks of the machines" is an acceptable substitute for good engineering practice, most thrown aside in the vendors' rush to put new products in the hands of county officials with tax dollars to burn.
Molpus completely misunderstood the Sequoia lawsuit. Sequoia did not support lawsuits against election officials; rather, one of Sequoia's top sales executives was indicted and convicted for his participation in an $8 million bribery scandal. If Molpus checks his facts, he'll see that rather than being rebuked, Sequoia is being rewarded with new contracts.
Theresa LePore, the same election official who signed the trade-secret contract for new machines in Palm Beach and who authorized inspection of those machines prior to the election by testing only the first candidate in each race, was rewarded by Florida Governor Jeb Bush with an appointment to the state's Select Task Force on Election Procedures (see Palm Beach Post, Nov. 25, 2002). Thus, Florida can look forward to more secret elections, with inappropriate and insufficient equipment testing for years to come. Sadly, other states (like Texas) seem to be following suit.
©2003 ACM 0002-0782/03/0200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.
No entries found