Alan S. Koch

“We don’t release software. It escapes!” (Carl, my former boss and a VP of Development) 

My former boss, Carl, once tried enticing me to join his management team by emphasizing how badly the company could use my process discipline skills; it worked.  I felt bad for them, and I was intrigued by the challenge. But, I learned at least as much as they did during my tenure there.

Over the course of my career, I have seen many instances of people failing at release management. In this article, I highlight eight statements that I have heard over the years from people in our line of work. Even though these people abide by these statements, they would never dare to repeat them out loud. I hope you will find inspiration not to follow these sayings!

A friend and fellow consultant has been known to react quite strongly to the phrase "best practice".  Anyone who is unlucky enough to have James within earshot when they utter that phrase is likely to receive a dressing down for using it. "There is no such thing as best practice!" he will inform them in his not-so gentle manner.  "There are only good practices that are appropriate under certain circumstances!"

Testing is such an integral part of our software projects that we often don't stop to think about why we do it. We must do it. What else is there to know? It is obvious that software that has not been tested is unready for deployment. As painful experience has taught us, testing does not guarantee that the software is fit to deploy. Even rigorously tested software may still have hidden fatal flaws.

A key part of planning configuration management for our projects is determining how we will manage change. After all, change happens and any good configuration manager is concerned with how it is managed. Unfortunately, more often than not, our processes focus more on controlling change than on managing it. That is, we put a lot of effort into trying to keep change from happening and relatively less effort into ensuring that when (not if, but when) change happens, we manage it effectively.

Every project is dependent upon people, processes, and tools:  they are how the work gets done. These three essential elements are not equal, though, as each has its own strengths and weaknesses.   Each one provides a different value to our projects.

"If they would just stop changing their minds!" Untold numbers of programmer’s rants have begun with that lament (including a few of my own). Of course, we know that will never happen. Change is a fact that we must live with and to avoid change is to avoid reality. The Agile method goes beyond merely acknowledging this reality. It teaches us how to capitalize on the changes that will inevitably come along to produce a better result than the one we planned for in the first place. We don't just accept change and we don't control it. Instead, we learn how to welcome change!

We need to choose an SCM tool. It will mean some work to make the choice and then more work to put it into practice. At least we don’t have to worry about it from a quality perspective, though. After all, the tools we choose to employ don’t affect the quality of the software we produce. Do they? Well, let’s think about this a bit. Hmmmmmm…

For many people, Agile software development congers up the thought of "undisciplined" software development. The reality is that using an Agile approach to its greatest benefit requires discipline in a variety of ways.  None is more critical than the discipline of software configuration management. Agile teams are generally small, but their SCM needs are big. 

Conventional wisdom tells us that standards are a good thing. They are based on best practices and provide guidance to help people do their jobs well. They are so widely accepted that their worth almost goes without saying. As with most things that go without saying, though, standards are not always what they are built up to be. In spite of the plethora of standards in the software industry, we still struggle to achieve successful projects. Even in organizations that are standard-centric, projects end up in challenged (or worse) states.

Many authorities have undertaken to lay out the one right way to engineer system requirements. Although there are similarities among them, what is most striking is the diversity in approaches and, in some cases, conflicting philosophies. What are we to make of these dueling authorities and their competing guidelines?

Traceability doesn't prevent errors and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools? On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.

"Sometimes," Bob mused, "It seems like senior management doesn't care about the quality of the systems we build. I wonder if they care about quality at all?"

"Oh, there is no question in my mind!" Sue assured him. "I know that they don't care. All they care about it hitting a schedule. They couldn't care less about how well the software works!"

Meanwhile, in the boardroom:  "What's wrong with your people?" the COO barked at the CIO. "They can never seem to deliver a system the works right. Between the bugs that have to be fixed and the difficulty that people have with figuring out how to use it, I wonder if we might be better off using pencil and paper!"

“But it was just a tiny little change! How could we have known it would cause such big problems?” Regression (going backward) is a fact of life in software systems. Even though something worked before, there is no guarantee that it will work after the latest "minor" change. Yes, modular design and sound system architecture can limit the likelihood of unintended effects, but they won't eliminate them all together.

All of us can think of examples of bad processes. They seem to be indelibly burned into our memories, but it may be hard to think of what a high-quality process looks like, because it feels like we've never seen one. Of course, that's not really true. All of us have experienced good processes; they are the ones that were invisible! Processes that are helpful, efficient and effective also seem to disappear into the background. Unless something draws our attention to them, we may not notice them at all!

"What does your quality assurance group do?" I have asked this question of many executives. Too often they answer, "Quality assurance is responsible for testing our software to ensure it is ready for release." I push, hoping for more, by asking, "Anything else?" Usually, though, the response is little more than, "Well, they manage the defect tracking system. What else would they do?" What more, indeed!

What is "quality"? There are many competing definitions, but the one that makes the most sense, "Quality is in the eye of the beholder," is hard to make workable in a real business situation. Some would say it is impossible to use, but Agile methods beg to differ.

Many people know that peer reviews can help them to produce better-quality products, but most organizations do not use this potent tool. Why? Because, although they would like to experience the quality benefits, they can't justify the costs they would incur.

In last month's column, "Reducing Your Cost of Quality," I listed "structured personal reviews" as being a highly effective appraisal method.  This resulted in e-mails from multiple people asking me about that topic.  So this month, I will explain what I mean by this term, and explain how you can make your reviews effective.

It was a restaurant my wife and I had passed many times, and we had always told each other, "We must try them some day." When we finally tried them, we were pleasantly surprised. The food, the service, the atmosphere, even the price were great! "This will be a regular stop for us," we agreed. But on our third visit, we had to send our food back twice. Another time, we waited nearly an hour for our order. Then, some time later, we were seated at a table that was not clean. Most of the time, things were great. But as we experienced sporadic problems, we visited that place less and less often.

What does it take to produce a high-quality product? A clear understanding of the customers' needs? Of course! Solid engineering work? Yes! Intensive testing? Naturally! Consistent practices? You bet! A committed, cohesive team? Without a doubt! Anything else?

Abstract
No one wants to deliver a poor-quality product. But our projects often seem like a struggle between the Quality Assurance personnel and those who have other jobs. Do some people really not care about quality? If that is not the case, then why does it so often seem that way?

It is time for a new build. What should be included in it? Obviously, it should include the latest and greatest versions of each module. Right?

When there is a quality problem with our products, where do we look to solve it? If we look to quality assurance, we will be disappointed. QA can measure the problem, and maybe even identify possible causes, but they cannot add quality to our products.