Pages: pp. 8-10
We often hear the term "best practices" used in software development contexts. Since I've been IEEE Software's editor in chief, I've seen the phrase in many submissions, a few of which have even proudly proclaimed in the title that they were presenting a best practice. Like countless others in the development community, I'd fallen into the habit of using the term indiscriminately for any activity that looked even remotely useful.
However, over the past several years, I've taken a serious interest in computer forensics, including looking for better ways to extract criminal evidence from suspects' hard drives. In a lot of ways, the problems are analogous to software engineering issues—a mixture of process and technology. Because of this similarity, I was surprised to find many of my law enforcement colleagues horrified by the idea of labeling something a "best practice." It turns out that in a criminal trial (at least in the US), the failure to follow an established best practice in an investigation could result in an acquittal. I learned it's far safer to avoid the term when discussing techniques investigators might use.
In software development, using (or failing to use) a best practice could have numerous ramifications. For instance, if your software fails, customers sue, and your organization didn't follow best practices, is that negligence? If your organization did follow best practices, is that a defense? Should customers select Company A's products over Company B's because Company A follows best practices? What exactly is a best practice?
The term "best practice" has several definitions, but the American Society for Quality's definition probably comes closest to what we in software development mean when we use the term. The ASQ defines "best practice" as a superior method or innovative practice that contributes to the improved performance of an organization, usually recognized as "best" by other peer organizations.
First of all, I'd like to state that I'm not fundamentally opposed to using the term "best practice" or its significance in establishing due care or negligence. I'm not even against using it to distinguish between competing products; in fact, I'd be very much for it. However, it's that last phrase in the ASQ definition that troubles me: usually recognized as "best" by other peer organizations. Although I think this phrase is important (in fact, essential) in establishing something as a best practice, it raises serious issues about how we determine what's a best practice to begin with:
The fact is that we really don't have a mechanism to formally establish best practices in the software development community. Of course, plenty of practices exist that most, if not everyone in the community, think are good ideas. But when does a good idea become a best practice? Frankly, I don't know. And, if "best practices" were just another slick advertising term that folks like to throw around, I wouldn't care. However, I fear that one of these days, adherence to best practices will mean the difference between negligence and responsible development in a lawsuit. We'd better have an answer by then.
As editor in chief of a fairly influential magazine dealing with software development, I consider this a serious question. If readers see an article, in this or any other publication, that claims an activity is a best practice, it's reasonable for them to think the activity is recognized as "best" by other peer organizations.
Because of this, I've begun restricting use of the term "best practice" in articles that we publish in IEEE Software. In most cases, "good practice" or "effective practice" serve as acceptable substitutes. I hope other editors consider similar measures for their publications. At the same time, I would welcome attempts to formalize its meaning for software development. Until we get there, be wary about using the term indiscriminately. It might come back to bite you or your company.
I'd like to hear your thoughts on best practices. What does it take to convince you that something is a best practice? Do you think we have any best practices (using the ASQ definition) in the community today? Please write me at email@example.com.
The Hawaiian greeting "aloha" is an acknowledgment that means hello or goodbye. I'd like to take this opportunity to say aloha to some old friends as well as some new ones.
Maarten Boasson, associate editor in chief for design, and Jeffrey Voas, associate editor in chief for quality, have completed their terms of service with IEEE Software's Editorial Board. They've both been instrumental in making IEEE Software what it is, and we all owe them a hearty thank you. But, in keeping with the aloha theme, it really isn't just "goodbye"; it's also "hello" because they're continuing with us as members of our Industrial Advisory Board.
Figure Maarten Boasson
Figure Jeffrey Voas
I'd also like to say aloha to two new Editorial Board members: Philippe Kruchten, who joins us as associate editor in chief for design, and Stan Rifkin, who will serve as associate editor in chief for quality.
Figure Philippe Kruchten
Figure Stan Rifkin
Philippe Kruchten is a professor of software engineering at the University of British Columbia in Vancouver, Canada. He has 28 years of industrial experience developing large-scale soft-ware-intensive telecommunications, aerospace, defense, and transportation systems. He spent 17 years at Rational Software, now part of IBM, where he led the development of the Rational Unified Process, a Web-based, generic software development process. He wrote three books on the RUP and created a model for representing software architecture based on multiple coordinated views, which led to an IEEE standard. He coauthored the Object Management Group's Software Process Engineering Metamodel, an industry standard for process modeling. He also represented Rational on the industry advisory board of the Software Engineering Body of Knowledge project. As a member of the International Federation for Information Processing Working Group 2.10 on software architecture, he leads the steering committee for the Working IEEE/IFIP Conferences on Software Architecture.
Philippe received his diploma in mechanical engineering from École Centrale de Lyon, France; his doctorate in information systems from École Nationale Supérieure des Télécommunications in Paris; and his certificate in intercultural studies from the University of British Columbia. Find out more about Philippe at http://philippe.kruchten.com or at www.computer.org/software/experts.
Stan Rifkin is known throughout the software engineering community. He is a principal at and the founder of Master Systems, a software consulting company.
Stan helps clients implement engineering and management process improvements. He also helped establish and participated in several software engineering process groups and software process improvement network groups.
Stan cowrote (with Priscilla Fowler) Software Engineering Process Group Guide, considered a seminal work on how to establish and sustain a SEPG and related software engineering process improvements. The guide has had major influence on the proliferation of grass-roots SPINs around the world. He also cowrote Measurement in Practice, a study of the US's best metrics practices, and recently wrote "Why New Software Processes Are Not Adopted" for Advanced Computers. Rifkin previously served on the editorial board of Empirical Software Engineering.
He earned his BS in business administration (quantitative methods) from California State University at Northridge and his MS in computer science from the University of California at Los Angeles. He also did PhD-oriented postgraduate study in applied science and engineering at UCLA and the University of Geneva, Switzerland. He is currently a doctoral fellow in executive leadership at George Washington University. You can find out more about Stan at www.master-systems.com/Stan.ivnu or at www.computer.org/software/experts.
To all of these individuals … aloha!