• Testing - no matter how good your programmers and processes, you still need testing to ensure good products.

Usability Testing Usability testers have started trying to do field testing. Instead of giving the subject tasks to do in a highly contrived environment, you conspire to watch the subject doing their own work at their own desk while you hide in a nearby shrub and spy on them. This method is most useful when you already have a version n of your product and you're trying to figure out how to improve version n+1. (Aug. 2005 Joel on Software)

Vendor management hinges on tiny details One IT staff was seeing obvious software bugs in the outsourcer's code. But the contractor didn't want to classify them as defects. Then it found out that the offshore programmers were compensated based on the amount of defect-free code they produced, so there was a disincentive to call anything a defect. (Mar. 2005 ComputerWorld)

Durability of Usability Guidelines Of 944 usability guidelines from 1986, 70% continue to be both correct and relevant today. There is much good advice, for example, on dealing with entry fields and labels on online forms, which have changed little from the dominant mainframe designs of the 1970s. The guidelines for error messages, system feedback, and login also hold up. (Jan. 2004 Jakob Nielsen)

Thoughts :: Fear of Change The most common reason for rejecting changes is a poor quality product. Poor source code, for example, could generate a product which compiles with the functional requirements, but which is a maintenance nightmare. If the developer who should implement the change is not the original author of the code, the situation gets worse. (Dec. 2003 The QP Project)

Of Code Reviews And Donuts Amidst blank stares and soft snoring, the developer translates into pseudocode, praying that feedback won't mean any rework. The code review that feels like hours usually ends in less than one. Yet, the code is usually no more stable, defect-free, or maintainable. (Nov. 2003 Intelligent Enterprise)

The Future of Software Bugs There are no standards for measuring software quality, broadly defined as functionality, reliability, usability, efficiency, maintainability and portability. But there's a long-term effort under way prompted, in part, by the bug that caused the 1999 crash of the Mars Polar Lander on Mars. (Oct. 2003 Computerworld)

Escape from Documentation Don't document if your product is vaporware. Why document code that never leaves the developers' machines, and maybe doesn’t run there either? No one will ever need written instructions about how to install or deploy it, and customers won't need help figuring out what never ships. (Oct. 2003 StickyMinds)

The Importance of Internalizing Quality Low external quality means developers create designs and code around incorrect assumptions. Internal quality measures how easily a program can be changed without breaking existing features. Software organizations often fail to identify which category of quality is deficient in a broken product. (Aug. 2003 CIO Update)

Want-Ads for QA that Nobody Really Wants Wanted: Hands-on QA manager with proven track record in writing automation harnesses and FDA documentation. Must know ISO9002 and Six Sigma. With development experience in C++ and Java. MBA with legal and brokerage experience, and double-byte localization. Well, maybe I'm exaggerating, but you've all seen QA ads like this, asking for a person who doesn't exist. (Jun. 2003 StickyMinds)

Application failure linked to material revenue loss: survey Given only one choice, 63% of respondents said that meeting business requirements has the most significant impact on the business. Reliability, and application availability and uptime, came in at 17% and 10%, respectively. (Jun. 2003 Xephon)

Stop making a meal out of your IT It is early Friday night when a help-desk operator answers the first of what will be an avalanche of calls from angry customers. The security group identifies the problem as errant code, but no one informs the help desk... The Information Technology Infrastructure Library (ITIL) was developed by the British Government to establish the best ways to manage a business's IT infrastructure based on the experience of practitioners from across the world. (May 2003 Sidney Morning Herald)

Spread of buggy software raises new questions Developers say defects stem from several sources: software complexity, commercial pressure to bring products out quickly, the industry's lack of liability for defects, and poor work methods. The Sustainable Computing Consortium wants to create automated tools that analyze software and rate its reliability. (Apr. 2003 CNN)

Midterm Improvement The early release of a low-functionality product to the customer explains more than one third of the variation in product quality across all projects. A second practice responsible for significant quality improvements is a daily build in conjunction with regression tests. Finally, a high-level of investment in architecture and design also shows a strong association with high-quality products. (Mar. 2003 Software Development Magazine)

A Man, a Dog, and a Machine Human error by system operators and during system maintenance is a major source of system failures. System failures are always caused by an unanticipated chain of events. It therefore behooves us to design in failure modes right from the start. (Jan. 2003 IEEE Computer Magazine)

Strike Three - Time for a New Batter In the late 1970s the software quality problem was all too apparent. Software was hard to write, hard to maintain, and often failed to meet its requirements. The search for better ways to write code was on. Unfortunately, the search still continues. Software is still buggy. (Jan. 2003 StickyMinds)

Well Principled (and Practiced) Software Development Being forced to use libraries that don't meet my own standards of quality or "good design" significantly lowers my own feelings about the quality of the work I am doing. Eventually it gets harder and harder to work up enthusiasm about creating the highest quality software. And that means that after a while developing software in such an environment is simply not fun anymore. (Dec. 2002 C/C++ Users Journal)

Quality To Go An application might work fine under in-house testing but create problems when integrated into a large, heterogeneous environment. For an organization to find people skilled in say, all the fine points of the Java platform or .NET, as well as having a deep understanding of Oracle databases or IBM mainframes, is next to impossible. (Sep. 2002 Software Development Times)

Building Solid Software Developing automatic error-prevention tools for the software industry is more complicated and expensive — by several hundred orders of magnitude — than simply preprogramming chip testers. Not embracing these tools requires software companies to seriously consider their longevity in a business that can no longer ignore quality lapses. (Aug. 2002 CIO)

Why Software Is So Bad Software engineers say code is bloated, ugly, inefficient and poorly designed; even when programs do function correctly, users find them too hard to understand. Groaning beneath the weight of bricklike manuals, bookstore shelves across the nation testify to the perduring dysfunctionality of software. (Jul. 2002 MIT Technology Review)

Quality First Of 800 business-technology managers responding, 97% report problems with software bugs and flaws in the past year, and nine out of 10 report higher costs, lost revenue, or both as a result. Companies have become so dependent on software that any failures carry the threat of irreparable harm to their businesses -- especially if systems are supposed to operate around the clock. (May 2002 InformationWeek)

Breaking Tradition The vague consensus is that a legacy application has been with the enterprise longer than the programmers who are now maintaining it, lacks good documentation, and has untouchable code. But the one characteristic I can see is that it's monolithic. This is a matter of programming and not age. (Feb. 2002 Intelligent Enterprise)

The Cranky User: Could you repeat that in English? Years ago, a friend of mine used a compiler that had only one diagnostic message: "Error in code." Not even a line number. Multics used Latin for all error messages; the intent was that this would prevent the end users from trying to outsmart the system, and would encourage them to call the adequately trained support staff to determine the nature of the problem. (IBM DeveloperWorks)

Practice, Schmactice! I've encountered people who explicitly shunned good software development practices, and I've had to work on the legacy software they left behind. I've known people who each deliberately became the Grand High Lama of complex, irreplaceable software systems—to make themselves indispensable—and then took steps to make those systems indecipherable to anyone else. (Jan. 2002 Software Development)

Writing Understandable Code The average developer overemphasizes capability and function while undervaluing the human understanding that effects improved development and continued utilization. There should be a description — in clear view — within the programming medium. (Jan. 2002 Software Development)

Brevity versus usability Users looking for all customers in Paris, France were confused by the error message "Search criterion missing." What these users didn't know was that the system required users to enter a customer name as well as a city. I recommended that the message articulate the problem with something specific, such as: "You must enter a customer name in addition to a city." (June 2001 IBM)

Achieving Usability Through Software Architecture To create usable systems, designers must first ensure that their proposed products provide the functionality their users actually need to perform work as opposed to the functionality that the marketing or development team imagines they need. (June 2001 Carnegie Mellon SEI)

Place Tab A in Slot B So, what types of documents will you need to produce? Your users may require a reference manual, a users guide, a support guide and even training materials. Operations personnel are often concerned with a system's interaction with other systems, databases and files. For maintenance professionals, the primary artifact is quality source code. (June 2001 Software Development)

Software Measurement: What's In It For Me? The biggest obstacle to implementing a successful software measurement program is getting the developers—the ones in the trenches designing, coding, documenting and testing the software—to measure their work. Who wants his boss to know that the guy in the next cubicle wrote more code than he did last week? If you're the first in your organization to look at measuring the quality of your team's output, where do you start? (Mar. 2001 Software Development Magazine)

The Seven Habits of Highly-Efficient Developers When AT&T assessed the performance of their engineering teams, they discovered that their top-ranking software developers were as much as 10 times more productive than their colleagues. There are several reasons behind this astounding range in performance - besides intelligence and aptitude, of course. (Feb. 2001 DevX)