For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.



Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.


Understanding Your Organization's Best Software Development Practices

David Herron

Understanding or identifying your organizations best practices is not a difficult thing to do. The challenge for most organizations is that they have to work within the context of preconceived notions as to what a best practice really means and the misconception of how it should be effectively deployed. A best practice, as we will soon learn, can have a significant impact on an organizations ability to improve performance within the software development lifecycle and to deliver quality products on time and within budget. Unfortunately, it can also become that ill-fated silver bullet that fails to produce the anticipated or desired results. The way forward is for an organization to understand clearly how to recognize a best practice, what makes for successful execution and ultimately how to identify their own best practices. We have all read articles about software development best practice of one kind or another. Sometimes these articles entertain us with first-person stories about how a particular development method, technique or development tool has had a positive impact on the development and delivery of software.

Over time, as we continue to hear more about a particular technique or software process that has provided positive results, we come to label these occurrences as best software practices. And, I think that for the most part, the label is deserved. The relevant question at this point is to ask ourselves, what is the nature or what are the characteristics of a software development best practice.

Characteristics of a Best Practice

If we are to identify software best practices within our own organization, we first need a common definition upon which we can all agree. And as part of that definition, identify the core characteristics that help us to distinguish something as a best practice.

Currently, I am not aware of any industry standard or certification process that is used to qualify something as a best practice; nor are there any rules or guidelines that help us to classify something as a best practice. We talk about frameworks like the CMMI (Capability Maturity Model Integration) as being a best practice or the Project Management Institute’s Body of Knowledge as being a set of best practices, but why do we? How do we know if something is a best practice? What gives a practice or a process that special distinction of being the ‘best’?

In this day and age, it only makes sense to make good use of the internet and do a Google search on the term “software best practices”. Here are a few of the ‘hits’ that came up.

“Best practices are generally-accepted, informally-standardized techniques, methods or processes that have proven themselves over time to accomplish given tasks. Often based upon common sense, these practices are commonly used where no specific formal methodology is in place or the existing methodology does not sufficiently address the issue.”[1]

“A method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. See also best in class and leading practice”.

And best in class was defined as:

“The highest current performance level in an industry, used as a standard or benchmark to be equaled or exceeded. Also called best of breed.”[2]

“In software development, a best practice is a well-defined method that contributes to a successful step in product development. Throughout the software industry, several best practices are widely followed. Some of the more commonly used are: an iterative development process, requirement management, quality control, and change control.”[3]

It would be difficult to find much of anything to really disagree with in the above definitions. They all sound about the same and the vast majority of people would agree that they could be accepted as a general definition of a best practice. If we examine these definitions a little closer we can find some key phrases that underscore some of the core characteristics of a best practice. Things like; generally accepted, proven over time, shown superior results and a well-defined method. These key words and phrases tell us that a best practice is quantifiable (shows results), relatively easy to understand (well defined) and has a history of success (proven over time). Let us look at two fairly standard quality related practices that are typically referred to as a best practice. In addition, let us see if we can apply these key words to these two practices.

The first one that comes to mind is the practice of conducting a formal review and/or inspection. Perhaps this was what was meant by ‘Quality Control’ in the previous definition. We all know that reviews and inspections involve the reviewing of artifacts such as requirements documents and design specifications for the purpose of identifying and correcting defects. The benefit of a formal review is to create a deliverable that is accurate and free of errors and omissions. I doubt there will be much debate among the readership that formal reviews could be classified as a best practice. The process for conducting formal reviews and inspections are very well defined (e.g., Fagan). There are specific measures (defect analysis) that quantitatively can tell us that it is effective. And formal reviews and inspections have been around…well, forever. The second practice that is often mentioned in a best practices discussion is requirements management. Requirements management as a best practice is a rigorous, definable and repeatable process that enables analysts to extract effectively requirements from a customer or end user. There are numerous methods for defining requirements, and so this best practice is not labeling a specific process, but it is addressing the practice or methods associated with good requirements management.

Once again, we can certainly fit requirements management to the general definitions noted above. It is generally accepted. Good requirements practices have been proven over time. And the techniques associated with these practices have been well documented.

A brief look at some of the measures that are associated with the above best practices include process compliance, defect density, effective removal rates and functional sizing. Process compliance is the basic practice of creating a formal mechanism to monitor and report compliance to a particular process. It does not provide insight as to the effectiveness or efficiency of the process but it does provide management with a view into the behaviors of the software development teams.

Defect density is often used to quantify and evaluate the number of defects attributed to a particular piece of software, systems application or software product. It is calculated by dividing the total number of defects found by the functionality delivered (measured in function points). The measure can be used to assess the overall quality of the software and also to predict the potential need for ongoing support.

The effective defect removal rate is used to measure the rate of defect removal throughout that lifecycle. The calculation involves calculating the number of defects removed at each phase of a lifecycle divided by the total number of defects discovered. This activity occurs at the various phases of a lifecycle. So for a waterfall lifecycle, you may have defect rates attributable to your requirements phase, your design phase, your coding phase, etc. This proves to be a very powerful quality measurement tool that provides insight as to the effectiveness of your quality practices. So these two examples present us with our first clue as to why something may be called or labeled a best practice: it works; it can be quantified; and it can be proven to be successful. Case in point - have you ever worked in a software development shop that has initiated a process improvement strategy to include reviews and inspections (an agreed upon best practice) only to see that program not well defined and therefore not properly executed, then sooner or later the practice falls by the wayside for one reason or another? I am sure you have. So was it a best practice or not? And if it does not work in your organization is it no longer a best practice? Of course not. It simply was not executed effectively and therefore it did not provide the ‘best’ results for that particular organization.

The point here is that a best practice such as design reviews or requirements definition is only as good as its execution. And the success of that execution is somewhat dependent upon measuring the process and the results. Measures do not make the process work better but they will provide information about compliance to the process, measure the output of the process and evaluate the impact; thereby ensuring the effectiveness and long-term use of the best practice. Measures will also ensure a return on the investment relative to the expense incurred to implement the particular best practices strategy.

Therefore, we have learned that in order for a best practice to be truly a best practice for any given organization it has to have some measure of success. Simply ‘doing’ the best practice is not enough. So when deciding to use one of these common and familiar best practices it is important to understand not only the techniques and methods but also the governance and measures of performance that will be used to ensure the best use of a selected best practice.

Effectively Implementing a Best Practice

It is hard to explain why more organizations are not following well-known and well-documented best software practices. The software industry is mature enough to have the basis of experience to understand that there are in fact better ways of developing and deploying software. Why wouldn’t an IT organization invest in the techniques that have been proven to have a significant impact on improving quality, delivering on time and satisfying the end user?

Unfortunately, I think the answer is simply that most organizations do not fully understand what it takes to implement successfully a best software practice. They buy into the concept, they want the results, but their expectations are not aligned with the reality of achieving a positive outcome. To underscore the point, in an article on the Nine Best Practices, the authors from Niwot Ridge Consulting, Niwot Colorado state that “In order for the Best Practices to be effective management must be engaged in specific ways.”[4]

In summary, they suggest that management engagement involves:

  • Commitment to the practices and the consequences of the practices. This commitment usually comes in the form of a formal endorsement of the process and the deliverables from the process. By officially sanctioning the Best Practices approach, both top management and all the participants agree in public that they are committed to make this work.
  • Action to implement the best practices. Have a commitment is easy, making good on the commitment is the hard part. The action needed to deploy the Best Practices will be managed just like any other project, with a detailed project plan, well-defined outcomes, and measurable deliverables.
  • Funding for the changes that will result from the practices. In order to accrue the benefits of the Best Practices, money must be spent. The actual funding details are not currently known. The total amount will be small compared to the total investment for the project. The return on this investment will be very large – a major contribution to the successful completion of the product.
  • Follow-up for the behaviors that result from the practices. Using the Best Practice of Project-Wide Visibility of Progress Versus Plan the deployment of the Best Practices will become a visible project.
  • Measurement of the outcomes of the practices. With measurement, management cannot take place. This is a Best Practice item that will be used for deploying the Best Practices.”.

Okay, so we have learned another lesson about best practices. Implementing a best practice is hard. It takes work and it takes commitment. Often times it requires changes in organizational behaviors and perhaps even changes in the culture. But if an organization truly wants to improve, it must adopt known best practices or find some other way to position them to be executing at a performance level that will yield positive results.

We have been talking about known software development best practices as recognized methods and techniques that can be adopted by organizations and when properly executed can lead to success.

And we have also learned that just because something is labeled as a best practice there is no guarantee that it will be properly implemented and yield positive results.

So a best practice is only a best practice if it is applied effectively within a given organization. If we look at that from a different perspective why wouldn’t we consider that there could be any number of development practices, techniques, methods within an organization that are yielding positive results. Therefore, wouldn’t those constitute best practices for that organization? After all, isn’t that what is really most important—to discover our own best practices.

We have learned that two characteristics of a best practice are that it is well understood and that it provides positive measureable results. We need to have the means to be able to understand and to assess our current development practices. The assessment should have measures of performance as well as providing clear insight as to what specific practices are providing positive results. In other words, what are our current best practices? If we can isolate those instances where we are effectively designing, developing and deploying software then we can learn from our own internal experiences and provide that knowledge across the organization.♦


[1] Wikipedia, The Free Encyclopedia.

[2] Business Dictionary.

[3] Search Quality Software.

[4] Niwot Ridge Consulting.

Read more IT Performance Improvement

This article is an excerpt from:

The International Function Point Users Group (IFPUG), a nonprofit and member-governed organization, has become the recognized leader in promoting the effective management of application software development and maintenance activities. Edited by IFPUG's Management and Reporting Committee, The IFPUG Guide to IT and Software Measurement brings together 52 leading software measurement experts from 13 different countries who share their insights and expertise. Covering measurement programs, function points in measurement, new technologies, and metrics analysis, the text is useful for IT project managers, process improvement specialists, measurement professionals, and business professionals who need to interact with IT professionals and participate in IT decision-making. It includes coverage of cloud computing, agile development, quantitative project management, process improvement, measurement as a tool in accountability, project ROI measurement, metrics for the CIO, value stream mapping, and benchmarking.

About David Herron

David Herron is a Business Development Manager and VP of Knowledge Solution Services for David Consulting Group. Over the course of his professional career David has provided consulting and coaching services for a variety of IT organizations throughout the US and Canada. He is an acknowledged authority in the areas of performance measurement, process improvement and organizational change management. He is a noted author and lecturer, and is a co-author of several books on topics relating to IT performance measurement. He can be contacted at