Slashdot Mirror

bfwebster writes "During the past few years, I served as an IT expert witness in BanxCorp v. Costco et al., in which BanxCorp sued Costco and Capital One for citing (with credit) its web-published national averages for CD and money market rates in their advertising. Judge Kenneth M. Karas issued his summary judgment opinion last fall, finding that BanxCorp's published averages are 'uncopyrightable facts' due to the simple calculation involved and the lack of ongoing human judgment in what banks were involved. Here is my summary of his findings, along with a link to the actual ruling."

bfwebster writes "Independent of one's personal opinions regarding the desirability and forms of government-mandated health care reform, there exists the question of how well HR 3200 (or any other legislation) will actually achieve that end and what the unintended (or even intended) consequences may be. There are striking similarities between crafting software and creating legislation, including risks and pitfalls — except that those risks and pitfalls are greater in legislation. I've written an article (first of a three-part series) examining those parallels and how these apply to HR 3200."

bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important." Read on for the rest of Bruce's thoughts on this book. Why New Systems Fail: Theory and Practice Collide author Phil Simon pages 251 publisher AuthorHouse, 2009 rating 8/10 reviewer Bruce F. Webster ISBN 9781-4389-4424-1 summary Risks and pitfalls of enterprise COTS projects Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.

Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.

What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.

The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.

The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.

The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.

The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.

The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.

The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.

Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.

While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.

My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.

In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering.

You can purchase Why New Systems Fail: Theory and Practice Collide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important." Read on for the rest of Bruce's thoughts on this book. Why New Systems Fail: Theory and Practice Collide author Phil Simon pages 251 publisher AuthorHouse, 2009 rating 8/10 reviewer Bruce F. Webster ISBN 9781-4389-4424-1 summary Risks and pitfalls of enterprise COTS projects Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.

Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.

What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.

The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.

The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.

The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.

The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.

The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.

The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.

Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.

While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.

My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.

In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering.

You can purchase Why New Systems Fail: Theory and Practice Collide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

bfwebster writes "US District Court Judge Andrew Gilford (Central District of California) granted a summary judgment motion in DealerTrack v. Huber et al., finding DealerTrack's patent (US 7,181,427) — for an automated credit application processing system — invalid due to the recent In re Bilski court decision that requires a patent to either involve 'transformation' or 'a specific machine.' According to Judge Gilford's ruling, DealerTrack 'appears to concede that the claims of the '427 Patent do not meet the "transformation" prong of the Bilski test.' He then applied the 'specific machine' test and noted that, post-Bilski the Board of Patent Appeals and Interferences has ruled several times that 'claims reciting the use of general purpose processors or computers do not satisfy the [Bilski] test.' Judge Gilford analyzes the claims of the '427 patent, notes that they state that the 'machine' involved could be a 'dumb terminal' and a 'personal computer,' and then concludes: 'None of the claims of the '427 Patent require the use of a "particular machine," and the patent is thus invalid under Bilski.' DealerTrack apparently plans to appeal the ruling. Interesting times ahead."

bfwebster writes "A set of pharmaceutical process patents for 'evaluating and improving the safety of immunization schedules' (Classen v. Biogen et al.; see US Patents 6,420,139; 6,638,379; 5,728,385; 5,723,283) were held to be invalid due to unpatentability. The decision was appealed to the US Court of Appeals for the Federal Circuit, but was upheld with a terse citation to In re Bilski (which decision we discussed here). Here's the entire text of the appeals decision: 'In light of our decision in In re Bilski, 545 F.3d 943 (Fed. Cir. 2008) (en banc), we affirm the district court's grant of summary judgment that these claims are invalid under 35 U.S.C. 101. Dr. Classen's claims are neither "tied to a particular machine or apparatus" nor do they "transform a particular article into a different state or thing." Bilski, 545 F.3d at 954. Therefore we affirm.' It will be interesting to see what happens when these same standards start getting applied to software-related patents."

bfwebster writes "Orin Kerr over at The Volokh Conspiracy (a great legal blog, BTW) reports on a US District Court ruling issued just last week which finds that doing hash calculations on a hard drive is a form of search and thus subject to 4th Amendment limitations. In this particular case, the US District Court suppressed evidence of child pornography on a hard drive because proper warrants were not obtained before imaging the hard drive and calculating MD5 hash values for the individual files on the drive, some of which ended up matching known MD5 hash values for known child pornography image and video files. More details at Kerr's posting." Update: 10/28 16:23 GMT by T : Headline updated to reflect that this is a Federal District Court located in Pennsylvania, rather than a court of the Commonwealth itself.

bfwebster writes "Microsoft has lost its appeal to remove class-action status for the 'Vista Capable' lawsuit that has already resulted in some embarrassing internal e-mails being released publicly. As Computerworld reports, in its appeal to the US Ninth Circuit Court, Microsoft argued (among other things) that 'continuing the lawsuit might mean new disclosures of insider e-mails, which could "jeopardize Microsoft's goodwill" and "disrupt Microsoft's relationships with its business partners."' Given what's been released so far (158-page PDF), not to mention Microsoft's history of rather frank internal e-mails, that's probably putting it mildly. There could be some interesting reading ahead."

bfwebster writes "According to a local news article from last week, Kentucky state lawmaker Tim Couch wants to ban anonymous posting on the internet in order to 'cut down on online bullying', which he says has been 'a particular problem in eastern Kentucky.' His bill would require posters to register with their real names and e-mail addresses under threat of fines. Looks like another battle in the right for anonymous free speech."

bfwebster writes "Space.com has an article talking about the efforts to observe the arrival of the Phoenix lander on Mars this coming May using current Mars orbiters. This community will likely be intrigued to see the ways in which NASA is using existing landers and orbiters to prepare for, and then monitor, that landing. This includes using the landers Spirit and Opportunity to simulate transmissions from Phoenix as a testing procedure in advance of the actual landing; using the Odyssey orbiter as a high-speed data transmission link from Phoenix to Earth during the landing; and using the Mars Reconnaissance Orbiter and Mars Express orbiter as backup data stores for Phoenix data transmissions during the descent. How long until we get a terabyte solid-state dataserver (running IPv6, natch) in orbit around Mars?"

bfwebster writes "Microsoft is currently facing a class-action suit over its designation of allegedly under-powered hardware as being 'Vista Capable.' The discovery process of that lawsuit has now compelled Microsoft to produce some internal emails discussing those issues. The Seattle Post-Intelligencer has published extracts of some of those emails, along with a link to a a PDF file containing a more extensive email exchange. The emails reflect a lot of frustration among senior Microsoft personnel about Vista's performance problems and hardware incompatibilities. They also appear to indicate that Microsoft lowered the hardware requirements for 'Vista Capable' in order to include certain lower-end Intel chipsets, apparently as a favor to Intel: 'In the end, we lowered the requirement to help Intel make their quarterly earnings so they could continue to sell motherboards with 915 graphics embedded.' Read the whole PDF; it is informative, interesting, and at times (unintentionally) funny."

bfwebster writes "The physicist John Wheeler famously quipped that 'Time is nature's way to keep everything from happening at once.' The web flattens time by making more of the past accessible. Here, then, is a reprint of BYTE's official review of the original 128KB Macintosh from the August 1984 issue. The article highlights the radical break with other PCs that the Mac represented, while at the same time giving the first real warning of Steve Jobs's least-productive tendency: pre-emptive and often arbitrary constraint of end-user options (e.g., no memory expansion on the 128KB or announced 512KB Macs, even though the 68000 processor had a lovely, flat 16MB address space, as opposed to Intel's 808x segmented hell)."

bfwebster writes "The latest update from NASA now gives 2004 MN4 a 1-in-37 chance (probability of 2.7%) of hitting Earth on April 13, 2029. That's a bump up from the 1-in-46 (2.2%) odds given this weekend and almost a 10x increase in probability from the original 1-in-300 odds announced late last week. Interesting times, indeed."

bfwebster writes "Space.com has a story on the scientists and technicians working on the Mars rovers, Spirit and Oppotunity--and how they will react when the rovers finally break down, go silent, or otherwise die. Of course, humans becoming emotionally involved with hardware is high on the list of overused science fiction cliches (see I.14), and humans were naming (and anthropomorphizing) their cars long before they started doing it to their computers. Some argue that anthropomorphic design can ease end-user acceptance [PDF], with some interesting results among toys for children. On the other hand, when software manufacturers try to give our computers some 'personality', we tend to vehemently react against it--witness Microsoft's attempts with the much-loathed Bob and Clippy. And when our personal computers are aged or ailing or simply misbehaving, we usually are more than happy to put them out of our misery. So in the case of Spirit and Opportunity, the issue may be the large investment of time, money, and professional credibility in having two semi-autonomous rovers 100 million miles away function correctly. Best quote from the Space.com story: when Spirit, early into its mission, shut down for reasons then unknown, the Spirit mission manager happened to get a phone call from her husband. He asked her how her day had been, and she said, 'Well...I think I'm personally responsible for the loss of a $400 million national asset.' Doncha hate it when that happens?"

bfwebster writes "In a striking example of how a preliminary (but wrong!) scientific conclusion can persist for decades, Space.com has a story about how the south polar ice cap on Mars is mostly water, not mostly carbon dioxide (dry ice), as has been stated since the late 1960s. The new finding is based on analysis of Mars Observer readings that show that the souther polar ice cap is too warm at certain seasons to be dry ice. This finding has negative implications both for those claiming that liquid flow structures on Mars were caused by C02 instead of H20, as well as those who were hoping to use all that CO2 for terraforming."

bfwebster writes "The Washington Post has a commentary by one of its regular columnists, Marc Fisher, on why computer users hate what he terms 'our techie masters.' One of his more pungent and, I suspect, on-the-money comments: 'Computer training has become the living hell of the American workplace...each new system is more confounding than the last, and each new product strips away many of the advantages of the previous system.' Not a Luddite screed; more an angry outburst asking why commercial software systems are often so wretched. Worth reading and pondering."