TEAM Zarate Tarrani Notes From the Field

My special friend, Muthukumar U sent me an interesting article titled Lemon Law for Software? that is completely in line with my thoughts on the subject. This article proposes the opposite of UCITA (discussed in previous entries). As an aside, I should be in Kuwait in a few weeks, and may have the opportunity to meet Muthukumar in person. He and I have been corresponding for nearly a year, and have collaborated on projects in the past. He's a risk management analyst for HSBC Bank Middle East in the Sharjah, UAE offices, so we'll be close enough to visit.

Kate reported in her 2 April entry that Microsoft's anti-Unix campaign backfires. Here's an update that is sure to bring another smile: Anti-Unix site returns - on MySQL? - at least they managed to move the site to IIS ... of course, they'll probably have to hire two additional bodies to keep up with the security patches, and an additional dozen to monitor security. The question I have is, how did they even become a monoploy? Sounds more like a stand-up comedy routine to me.

Culture and Process. One of the most interesting articles I've read in a long time is Cultural Obstacles to Measurement and Process Maturity. This article validates the assertions Mike has made here in previous entries, but I am not entirely sure I concur with all of the author's conclusions. In a nutshell, the article posits that,

[I]t's easier to implement CMM in a "prescriptive" culture. Professionals from cultures with a history of British dominance tend to embrace prescriptive models with far less resistance than their American counterparts.

I personally believe the thesis that there is a difference between prescriptive and the ad hoc nature of the U.S. culture. I'm not quick to buy into the history of British dominance part. Is it a coincidence that CMM level 1 is defined as ad hoc and the cultural nature in the United States can be described as such? I think not.

That said, I do agree with the intent of the article, to show that there are cultural gaps and the implied message that we need to become more procedure-oriented. What I see as the root of the problem is that we in the U.S. are more focused on management, when it takes leadership to establish and maintain a culture of process maturity. I believe a closer examination of the problem will reveal insights that this article to another level. Regardless of my disagreement with portions of the article, however, I hope it gets read by a wide audience (which is why I chose it as my topic), and the cultural barriers to implementing process maturity in the U.S. as the rule rather than the exception fall.

What I'm Reading. One of the reasons I've been keeping such a low profile is because I'm immersed in Building Secure Software: How to Avoid Security Problems the Right Way by John Viega and Gary McGraw. I'll be posting my review of this book on Amazon and here Saturday night, but in the interim I want to mention that this book is absolutely essential reading if you have any role in the software development projects.

Another book that has received unanimous rave reviews is Writing Secure Code by Michael Howard and David Leblanc. Ironically, this book is published by Microsoft Press.

I haven't read it, but judging from comments this is another essential book for anyone who is serious about developing secure software, and is on my list of books to buy and read. Lest you question the credibility of this book because of Microsoft's notoriety for insecure software (as reported by the trade press), bear in mind that Microsoft Press publishes books by authors who have no connection with Microsoft's business other than writing books. Therefore, do not discount this book until you've checked it out - something that I plan to do.

Run, Forrest, Run. Yes, you can cast off the braces that shackle you and run like the wind. The case study about Life Time Fitness and How to Bid Farewell to Microsoft shows that you can escape. Also worth reading: Bad Software Can "Enronize" Anyone.

Web Services. Nobody seems to agree on the exact definition of web services, but that doesn't stop it from being a hot topic. Imperial Sugar Rebuilds on Web Services is an excellent case study of how to look beyond the buzzwords and muddled definitions and harness technology to meet business requirements (which were dire in this case). Linda and I reviewed two books that look beyond the trendy definitions and go to the heart of practical use(s) of the technology:

1. Architecting Web Serivces by William L. Oellermann Jr. (Linda's 17 December 2001 review; my 13 December 2001 review)
2. Building Scalable and High-Performance Java Web Applications Using J2EE Technology by Greg Barish (Linda's 3 April 2002 review; my 4 April 2002 review)

Risks & Requirements. The April 2002 issue of CrossTalk is out and is essential reading for project managements, software engineers, and requirements analysts.

What's inside:

• Risky Requirements. Three articles addressing aspects of the April issue's theme:
  1. Requirements Risks Can Drown Software Projects
  2. Recommended Requirements Gathering Practices
  3. Reducing Risks Through Proper Specification of Software Requirements
• Two articles about software engineering technology:
  1. Seven Characteristics of Dysfunctional Software Projects
  2. Add Decision Analysis to Your COTS Selection Process
• In the Open Forum section: Prerequisites for Success: Why Process Improvement Programs Fail, and the issue's final article, Mapping the Capability Maturity Model

Good stuff all! I am always enamored with articles that provide quantitative measurements, processes and lessons learned, and this issue has it all.

My bliss after reading the entire issue was leveled by the Backtalk section. This is the last page in each issue and is usually a humorous look at some aspect of the theme. However, this column, titled Risqué Requirements, had more stark truth than humor (not that it wasn't facetious in its own way). The guest columnist, Gary Petersen, wrote what I consider to be one of the most incisive analyses on what's wrong with our profession that I've had the pleasure and pain of reading in a long time. I'm tempted to quote and provide my own analysis, but it would only diminish the clear message that Mr. Petersen broadcasts. I encourage you to carefully read the article, then download it, then send it to your friends, enemies and everyone else who works in software engineering in any role.

April Fool? Mike's facetious 1 April entry was no joke. There is more to add about what I consider to be poor integrity of products coming from Microsoft. As a competitive intelligence specialist I certainly see the advantage of having competitors using Microsoft products. However, since exploiting security holes is an illegal and unethical approach to gathering intelligence the exposures that are reported I cannot take advantage of the problems that seem to go with using Microsoft products.

In addition to the issues that Mike raised, here is another that was reported on 2 April: MS security patch fails on local files. It's no coincidence that Mike, Linda and I all use Netscape - we closely follow security issues and the reported problems with Microsoft products is one reason why we avoid using them when there are alternatives. Of course, there are barriers to escape as shown in Windows Messenger 'Trojan update'. Sounds like monopolistic behavior to me. Oh, I forgot - they're convicted of monopoly. Never mind.

One approach to resolving the problems is proposed by Sun's chief scientist, John Gage, in a 29 March interview with The Register. See Make Microsoft pay for bugs and BSODs - Sun's Gage for the full text.

Intellectual Property and Lunacy. The Gage interview is important for reasons other than Microsoft's problems - the true message is in his thoughts on intellectual property; specifically what he has to say about Surviving Valenti. Along these lines the Wired News article titled The Kazaa Ruling: What It Means is an outstanding analysis of intellectual property issues, especially as they relate to peer-to-peer and file sharing. It's a brave new world and the law makers just don't seem prepared to deal with it. But deal with it they must. See ElcomSoft squares up to Feds in Sklyarov test case. This is the first time in a case that will challenge America's controversial Digital Millennium Copyright Act (DMCA). In my opinion this is a good move. For more background see the 16 November 2001 article titled IP conference: copyright law has gone too far. Not only has it gone too far, it seems to cater to special interests and is anti-consumer. If you want to closely follow these issues read Lisa Rein's weblog - she is on top of the issues and pulls no punches when reporting them.

A Smile a Day. You just have to smile when you read reports like Microsoft's anti-Unix campaign backfires. Never ascribe to malice that which can be explained by stupidity. Just don't be stupid yourself - there's sage advice in Your Biggest Threat, and you'll do well to heed the advice.

Final Note. I'll be working with Mike on a project in Kuwait (Insh'Allah) - Insh'Allah means God Willing. And if He is willing, in a few weeks I will have an opportunity to engage in process design, developing reference data and applying knowledge management in support of service delivery goals. Salaam from Irvine, California.

Objective, Objectivity and QA. Late last week I received a message from the originator of RSI approach to use cases. RSI stands for "Requirements-Service-Interface". I first learned of this technique from Quality Web Systems: Performance, Security, and Usability. I was so impressed with the approach that I wrote in my 22 September 2001 review of the book:

[t]his book contained a real gem: RSI approach to use cases. RSI (Requirements-Service-Interface) is an interesting and highly useful approach to use cases. Some key strengths of using the RSI paradigm is that you will ensure traceability between requirements and the services and interfaces that are implemented. Moreover, this approach partitions services and interfaces, which allows you to manage the complexities when developing a test strategy and associated test cases. To me the chapter on RSI was worth the price of the book.

RSI's originator, Mark Collins-Cope, also wrote most of the chapter that so impressed me. The reason he sent me the e-mail is that he's gathering feedback on RSI, and is particularly interested in how I approached partitioning services and interfaces, and managing the complexities of developing a test strategy and associated test cases (I'm paraphrasing Mark's message). I do not have notes that I can share, but if you've used RSI and have supporting material please contact Mark. He's open to collaborating on a whitepaper.

Mark's company, Ratio Group publishes a valuable newsletter (ObjectView), and has a publicly available technical library that covers object-oriented development, component-based software engineering, UML and related topics. The documents are well written, detailed and of the same quality as chapters from major technical book publishers.

Manisha Saboo sent a Zip archive full of Usability Testing artifacts, which I'm sharing. Manisha's a top software quality professional who always has something interesting to say about quality, software engineering and related topics.

New and Newsworthy. The March issue of TUSC Client Chronicle is available (top item is Kevin Loney's article about online database block size rebuilds in Oracle 9i). Also the newest issue of The Data Administration Newsletter is available, as is the newest issue of Doug Kaye's IT Strategy Letter.

Good afternoon from Tustin, California.

Are you in a time warp? Have you visited this weblog or its sister, Postcards from the Revolution, discovered no new entries, then returned the next day to find entries that were date/time stamped as being posted during your earlier visit? You are not going crazy. We post our material, but don't publish it until one of the other team members has peer-reviewed it. In that respect we practice the same quality procedures that we preach. Invariably something will slip through, but it usually gets corrected by Kate Hartshorn who is one of the sharpest technical editors I know. As a team we all have come to depend on Kate's meticulous command of English and grammar, and I have grown to depend on her for much more. I'll leave that topic for another time.

Risky Business. I recently discovered a site that you'll want to bookmark: Risk Audit Benchmarks, which is like having an online list of common business risks a mouse click away. There are no long-winded dissertations, just a list of common risks for a number of business areas. Although it's little more than a memory jogger, it's a comprehensive one, as evidenced by the listing of list of internet based applications risks.

My Previous Entry. On the topic of risks above, and the software defect and project management discussions in my last entry, the paper titled Avoiding Premature Delivery of Software serves as a keystone for many of the topics I've introduced. Another paper that augments my last entry is Screening Contracts for Product and Process Development. There is a contradiction between the approach I advocate (the buyer is responsible for requirements) and the views of the authors that claim the seller is responsible. However, that does not diminish the value of the paper because the underlying message is to carefully examine your supplier's processes.

Security is Everybody's Responsibility. It is also an important consideration in any IT contactual arrangement. Security for IT Contracts is a paper that should be read and heeded by buyers and sellers alike.

Neat Packages. I'm going to wrap this up with two documents that support the ones in this entry and in my preceding entry: A single-page MS Word document that summarizes Deming's 14 points (think of it as either an inspiration or an extension of your conscience), and an IT Security Evaluation Manual (this 261-page MS Word document may save you days of effort and shave off a significant fee to consultants if you tailor it to your organization and employ it).

Good morning from Tustin, California.