Saturday, April 06, 2002

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.

Friday, April 05, 2002

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.

Thursday, April 04, 2002

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)

Wednesday, April 03, 2002

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:

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.

Tuesday, April 02, 2002

Scalability & Performance, Quality, Process and Outsourcing. The busy weekend is behind me and I'm ready to face the world of IT and work. Although many of my weekend activities were focused on family and the holiday, I found time to squeeze in a book review and consolidate a few loose ends. The book review first.

Building Scalable and High-Performance Java Web Applications Using J2EE Technology - Clear description of important concepts

While this book uses J2EE as the basis for scalability and performance strategies in web application development, it is also useful regardless of the development and technical environment.

The author begins this book with the clearest and easiest-to-follow descriptions of performance and scalability and how to measure them that I've ever read. The same treatment was given to web applications architecture, which is the second topic in sequence. I like Mr. Barish's straightforward, conversational writing style and use of simple (but effective) illustrations, graphs and examples that make complex concepts easy-to-grasp.

I stated above that this book can be used outside of the J2EE environment, and here are the chapters that are generic enough to accomplish this: 1 (Scalable and High Performance Web Applications), 2 (Web Application Architecture), 4 (Scalability and Performance Techniques), 5 (HTTP Client/Server Communication), 10 (Effective Database Design) and 12 (The Future of Web Applications). While each of these chapters are well written and go into sufficient detail for developers and architects I particularly liked chapter 10 because he explained relational database fundamentals and SQL programming with such clarity that I got more from the 42 pages that comprise this chapter than I did from a 300+ page book on the topic. The follow-on chapter on JDBC and SQL is as well written. Another reason why I liked chapter 10 is many developers understand how to develop servlets and components, but do not have sufficient understanding of relational databases. This book rectifies that, which is particularly important since most real world applications are data intensive and need to connect to databases.

Additional strong points about this book include: code examples are only given to reinforce a concept or show an example. Don't expect to find a recipe book based on code - this book is about making it scalable and giving it performance characteristics. The J2EE-specific parts of the book use realistic examples and propose real world approaches. However, the strongest aspect of this book is the author stays focused on scalability and performance throughout the book, always ending each chapter with scalability and performance hints that are related to the chapter's topic.

This book is for architects and software engineers who are building applications that support business-critical needs. It's clear, concise and exceptionally well written.

Loose Ends. I've recently discussed ISO 9001 and outsourcing in entries here and in Postcards from the Revolution. I am going to devote my next efforts to helping Mike describe the Tarrani-Zarate Model in Postcards from the Revolution, and before I embark on that I want to provide the remaining documents I have on ISO 9001 and outsourcing to cleanly close out those topics (for the time being - I'll revisit them at a later date). The documents are:If ISO 9000-3 is a topic in which you're interested you'll want to visit ISO 9000-3 1997 Guidelines in Plain English.

Parting Note. We frequently address security here and in Postcards from the Revolution. I just discovered International Security Technologies, Inc.'s page on Cost of Risk Analysis. This is a commercial product that is worth investigating. The site also has a collection of whitepapers that are valuable and informative, and independent of the product.

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.

Monday, April 01, 2002

Want Competitive Advantage? I think I've managed to come up with a strategy for achieving competitive advantage before Kate Hartshorn, our resident competitive intelligence specialist, thought of it. Here it is: pay for your competition's upgrades to Microsoft products. Dumb idea? It depends on whether you subscribe to Niccolo Machiavelli's approach to strategy. Consider the following recent news items, then draw your own conclusions:I wish I could say the above is in the spirit of April Fools day, but the sad truth is if you're using the products cited, or are considering an upgrade you may want devise a strategy for dealing with the exposures. You may also want to read my review of Acquisition: IT Due Diligence (one of the IT Manager Development Series books) in Postcards from the Revolution.
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.

Sunday, March 31, 2002

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.

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]