Food for Thought-An e-newsletter published by Software Quality Consulting, Inc. February 2008, Vol. 5 No. 2 Common Sense Isn’t All That Common What topics would you like to see in this newsletter? Each month, this newsletter tries to provide you with useful information. This is a two-way street and your feedback is important. Please send your thoughts and comments to steve@swqual.com. -------------------------------------------------------------------------------- Welcome to Food for Thought(TM), an e-newsletter from Software Quality Consulting (http://www.swqual.com/index.html?Intro). I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking the Forward Email link at the bottom of this email. If you’ve received this newsletter from a colleague and would like to subscribe, please click this Enter New Subscription link (http://www.swqual.com/newsletter/Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won’t be bothered again. Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to info@swqual.com. -------------------------------------------------------------------------------- *** In This Issue *** In This Months’ Topic, I discuss the lack of common sense in the software industry... Regular features to look for each month are: - Monthly Morsels Hints, tips, techniques and reference info related to this month’s topic - Calendar Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development -------------------------------------------------------------------------------- *** This Month’s Topic *** Common Sense Isn’t All That Common Every culture has its own collection of sayings, phrases, colloquialisms, and proverbs. These sayings often provide examples of what you might call common sense. And as I have observed, unfortunately common sense isn’t all that common... One of the most frustrating things about working in the software industry is the lack of common sense. I’m sure many of you have experienced firsthand numerous examples of decisions and actions that seem, well, just plain stupid. - How many times have feature changes been slipped in at the last minute, knowing that these changes will cause the application to become unstable and regress? - How many times have decisions been made to release products with dozens of known bugs - knowing that customers will not be happy and that unplanned bug fix releases will be required? - How many times has the same broken process been used yet again on another project only to achieve the same dismal results? Here then are some of my favorite examples of simple common sense and some suggestions for how you can inject some sanity into your work... - “A picture is worth a thousand words.” This is one of my favorite sayings because it is so obvious. Humans are much better at understanding graphical information than textual information, especially when we are dealing with complex concepts - such as the features in many software applications... Yet, we still try to express this complexity using a language that leads to many misunderstandings. Compounding this problem is the fact that the people writing requirements often have had little, if any, training in using English to express complex ideas in a manner that is clear, unambiguous, and easy to grasp. Here’s a simple example. The following are the requirements common to many applications that have passwords. These are the rules for changing a password. Requirements for changing a password... (OP = Old Password NP = New Password) User enters a new password (NP). Application determines if NP meets the following rules. 1. If OP is correct, NP and Confirm NP are same, NP passes configuration edit, and has not been used during prior two password changes, confirm change with a successfully changed password message. Display Message = Password successfully changed. 2. If OP is correct and NP and Confirm NP match but do not conform to configuration settings, a message describing error is displayed. OP, NP and Confirm NP are blank after user selects “OK” on error message. “OK” button brings user to Change Password screen. Error Message = Password you entered does not conform to format specified by your system administrator. Enter a valid password. 3. If OP is valid and NP and Confirm NP do not match, a message describing error is displayed. OP, NP and Confirm NP are blank after user selects “OK” on error message. “OK” button brings user to Change Password screen. Error Message = NP and Confirm NP entries do not match. Try again. 4. If OP is correct and NP and Confirm NP match and pass configuration but has been used prior by user during previous two changes a message is displayed. OP, NP and Confirm NP are blank after user selects “OK” on error message. “Ok” button brings user to Change Password screen. Error Message – Password used too recently. Try again.” 5. If NP and Confirm NP match and pass configuration but OP is invalid, a message is displayed. OP, NP and Confirm NP are blank after user selects “OK” on error message. “Ok” button brings user to Change Password screen. Error Message – OP entered is invalid. Try again. Now here’s the same requirements expressed as a simple flowchart... (See the online version for the graphic of this flowchart) Which is easier to understand? Clearly, the flowchart enables the reader to grasp the complexity more easily and with less confusion than the words. In addition, flowcharts provide added benefits for testers... - Flowcharts identify all the paths that need to be tested and also ensure that the default or “else” case isn’t left out as is often the case when requirements are written in English. What can you do? If you find the flowchart easier to understand, then look at your own requirements documents. Do they contain pictures, flowcharts, or other graphical means for conveying information? If they don’t, then... - Take a few examples of requirements from one of your past products. Represent these requirements using an alternative to English -- flowcharts, structured English, or use case diagrams. - Talk to the folks who write requirements. Show them how much simpler it is to convey complex requirements using these techniques... - Encourage them to attend a Requirements Writing workshop... (http://www.swqual.com/training/requirements.html) - “Measure twice, cut once.” One of my favorite TV shows is the New Yankee Workshop (http://www.newyankee.com/index.php) where master carpenter Norm Abram builds furniture seemingly without ever making mistakes. I’ve built some furniture using Norm’s plans and made many mistakes. Of course, Norm’s mistakes are edited out of the show but he always stresses the importance of getting the measurements right and of paying close attention to details... When developing software, the devil truly is in the details - thousands of them. This fact was illustrated in 1999 when NASA’s Mars Climate Orbiter crashed on the surface of Mars. A NASA review board investigating the crash found that half of the software engineering team thought that calculations were done using the English system while the other half of the team thought calculations were done using the metric system. Ooops! That little mistake cost us taxpayers $125 million. On the plus side though, since this incident, NASA has mandated the use of Independent Verification and Validation (IV&V) on all projects that involve software. Another set of eyes could have helped prevent this mistake. What can you do? - If your software uses units of measure, check, double-check and triple-check to make sure they are right and are used consistently. - You have to sweat the small stuff if you want to ensure your software doesn’t crash and burn like the Mars Orbiter. Every detail needs to be addressed, documented, and tested. - Attend a workshop on Software Verification and Validation (http://www.swqual.com/seminars/courses.html) - “When you throw dirt, you lose ground.” I believe this comes from an old Chinese proverb. Makes sense doesn’t it? When a project fails, rather than trying to learn from the failure, we often look for ways to make ourselves look good, usually at someone else’s expense. When we play the blame game and point fingers at others, the respect of those throwing dirt is diminished. Eventually, you’ll have no dirt left to throw. Maybe then you’ll realize that blaming others is not an effective way to learn from mistakes. Of all the stupid things software companies do, one that definitely is at the top of my list is making the same mistakes over and over again. What can you do? - When a project fails, identify root causes in a manner that doesn’t lay blame or point fingers. - Learn how to perform Root Cause Analysis (http://www.swqual.com/ training/root.html) for defects and projects... - If you work in an organization that tends to blame people or teams for failures, consider doing a Project Retrospective (http://www.swqual.com/ training/retrospectives.html) instead of an ineffective post-mortem. - “You only have one chance to make a first impression.” Whether on a job interview or a blind date, first impressions are critical for the relationship. If you make a bad first impression for whatever reason, it is often very hard to change the other person’s impression of you. On the other hand, if you make a good first impression, you might get a second interview or a second date! Well, the same is true of software - the first impression your customers have of your application is critical. When customers experience installation problems, they form negative opinions of your software, regardless of how good it may be. The same thing happens with patches, bug fix releases and service packs. Quite often, these releases are not fully tested and as a result, can do more harm than good. What can you do? - Understand the installation processes used by your customers and make sure you use the very same processes as part of your internal testing... - Incorporate Act Like a Customer TM (ALAC) testing into your testing process. ALAC TM tests are based on how users actually use your product. These tests are critical in helping to uncover the kinds of defects that users are likely to encounter. Creating ALAC tests requires testers with domain knowledge (http://www.swqual.com/newsletter/ vol2/no9/vol2no9.html)...a critical testing skill. - Learn more about Act Like A Customer(TM) Testing (http://www.swqual.com/training/testing.htm) - “You can pay me now or you can pay me (a lot more) later...” There used to be an ad for oil filters where an auto mechanic leans into the window of a car and tells the owner about the importance of changing the oil filter regularly. The owner seemed reluctant so the mechanic says, “Well, you can pay me now or you can pay me later. But if you pay me later, it will be a lot more.” Does this resonate with your last project? Some decisions made on projects are like deciding to not change the oil filter. It may save you a few bucks and a few minutes now but eventually, costs much more down the road... - “We never have time to do it right, but always have time to do it over.” By far, this is my favorite saying because I see this happening so often in our business. Management doesn’t understand that getting it right the first time is the most efficient way to work. From poorly written requirements, to inappropriate architecture and design, to badly written code, or insufficient testing, we always seem to find excuses to not do it right the first time. As a result, we muddle through projects and deliver something that we know is not going to meet customer expectations. The thinking is that we’ll fix it with a patch release. This illustrates what I call the “patch release mentality.” In the software business, there is an assumption that there will always be a patch release. So why not use patch releases as an excuse to deliver lower quality products? It should be obvious that the “patch release mentality” is not a cost-effective business strategy in the long run. With that, I would like to leave you with one last quote... "Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives." - William A. Foster ‘Til next time... -------------------------------------------------------------------------------- *** Monthly Morsels *** Every month in this space you’ll find additional information related to this month’s topic. - References 1 Weigers, Karl, Software Requirements,2 nd edition, Microsoft Press, 2003. 2 Kerth, Norm, Project Retrospectives: A Handbook for Team Reviews, Dorset-House, 2001. 3 Rakitin, Steve, Software Verification and Validation for Practitioners and Managers, 2 nd edition, Artech House, 2001. - Additional Resources: - Karl Wieger’s In Search of Excellent Requirements Course (http://www.processimpact.com/ISOER/index.html) - Steve McConnell’s Requirements Seminars (http://www.construx.com/Page.aspx?nid=4) - Norm Kerth’s Project Retrospectives website... (http://www.retrospectives.com/) -------------------------------------------------------------------------------- *** Calendar *** Every month you’ll find news here about local and national events that are of interest to the software community... - Software Quality Calendar There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. Find out what’s happening... (http://www.swqual.com/links/upcoming.html) - Workshops Offered by Software Quality Consulting Software Quality Consulting offers workshops in many topics related to software process improvement. Get more info...(http://www.swqual.com/ seminars/courses.html) -------------------------------------------------------------------------------- *** About SQC *** Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of clients. We help clients fine-tune their software development processes and improve the quality of their software products. The overall goal is to help clients achieve Predictable Software Development(TM) – so that organizations can consistently deliver quality software with promised features in the promised timeframe. To learn more about how we can help your organization, visit our web site (http://www.swqual.com/index.html?AboutSQC) or send us an email (info@swqual.com). -------------------------------------------------------------------------------- I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. Send me your feedback... Thanks, Steve Rakitin info@swqual.com Food for Thought, Predictable Software Development, Act Like a Customer, and ALAC are trademarks of Software Quality Consulting, Inc. Copyright 2008. Software Quality Consulting, Inc. All rights reserved. Graphic design by Sage Studio