The Four Hundred

How many of you perform specification reviews, code walk-throughs, and quality assurance testing in your organization? Have you looked closely at those processes lately? You may want to, because most of them have been infected with a terrible disease and it could be killing your ability to provide quality software to your customers and users. Simply having a process in place could cause this disease. So what's the cure?

I believe that properly done spec and code reviews, along with code testing, are vital to the successful completion and maintenance of application software. The keyword is properly. I have witnessed these processes practiced all too often by less-than-qualified and unmotivated people. This not only undermines the integrity of the software, in the form of undocumented features (bugs) and incomplete business requirements, but also costs a lot of money.

Joe User requests a change in the way a business process works. He fills out a business request form and submits it to the IT department. The next step is to actually approve the request. You must have a way to determine which requests are necessary. You may have a group of managers and supervisors who determine the fate of each request. It takes time and money to get these folks together in a room, but it's well worth the effort. They provide paramount duties such as duplicate and invalid request filtering, project prioritization, and cross-department communication. The latter function is important because many times one group doesn't know what another is doing, even if a project affects that other group. It is the one process that is least carried out, yet one of the most crucial for the business.

Once the request has been approved, a functional specification needs to be written. The purpose of the functional spec is to explain how the modification will flow through the application. It's a high-level IT document that tells what areas of the application and database will be affected. The functional specification should be assigned to a project leader or someone responsible for a specific portion of the application. That way the overall impact to the application can be better determined.

However, many times, the functional spec is assigned to a programmer, who will end up coding the modification. The programmer is usually more concerned with specific coding techniques and less about the overall picture. This may cause the programmer to throw something together quickly or not as thoroughly as necessary. No problem, right? The functional spec review team will catch any glaring errors, oversights, or shoddy work.

The review team, which should be made up of high-level application folks and business analysts, is usually made up of programmers and maybe a project leader or two. More times than not, the reviewers enter the meeting without ever having read the spec they are about to review, and therefore they have nothing to say. The meeting lasts a few minutes per spec and everyone adjourns, happy they have done their part for the betterment of the business. Meanwhile, any design flaws have been missed, and the longer those flaws remain undetected, the more costly they become.

The programmer, now halfway through the coding of the project, must stop what he is doing to write the detailed design spec, which is used to get down to the nitty-gritty. What database files will be used and created, what programs will be written and modified, what new technology will be implemented are all questions answered, as well as designed, in the detail design spec. Sounds good, right? Well, what usually happens in the real world is that what was written in the functional spec becomes moot because the programmer will never look at the functional spec anyway. Instead, he might just as well finish the coding and write the design spec based on the code that is produced. Not to worry, the design spec review team will stop any design flaws dead in their tracks, right?

The folks in the design review team are also on the functional review team, even though the two teams require different specialties. The programmer, to get through the spec, may have simply cut and pasted the code into the spec. This means that no one except the people who can read the code can actually understand the spec. The reviewers who can read the code are only concerned with the code, while the folks who can't read the code, but are concerned with the overall picture, are going to defer to those who can read the code, instead of demanding that the spec be rewritten. So in essence you've turned the design spec review into a code walk-through, without ever deciding if the design was correct. The project is coded, or almost coded, and has gone through multiple reviews, yet nothing has been accomplished. But everyone feels good about it.

Now it's QA's turn. They get the project and assume that it's sound and valid based on all the rigorous review meetings they've been through. In some cases, they depend on the programmer for the test plan. Enough said there. Then junior-level people who don't know much about the business or IT complete the testing. They are trained to look for generic problems, and because they are relying on the programmer for specific test cases, they don't always catch flaws or bugs.

So it turns out that the worst place to uncover logic flaws and bugs is the most common place to do just that--production. On more than one occasion, I have put forth a proposal to a company that skips the functional review, design review, and QA testing and goes straight from coding to production. I further proposed that doing so would not result in an increase in the number of problem calls from the user. In all cases I was looked at with serious concern, and my ability to reason was seriously questioned. These same people feel that having a process in place is enough. But the process must be properly carried out, or it is nothing more than a waste of time and money.

I know many of you out there know me and have worked with me and are probably saying, "Wow, Kevin is trashing the way we do business." You say this because you think that I am basing my software development cycle critique on the way your company practices it. You know what? You're all correct. Whoever you are and wherever we've worked together, I have witnessed some, if not all, of these problems. So please don't feel singled out or left out, because we're all in this together.

So how do we fix this? As I stated earlier, the process may be solid, but if it is not properly carried out, it does no one any good. There must be someone or a group of someones to filter out what is not needed and prioritize what is. The IT folks involved in the review process must understand the business processes and must take the time to go through the review documents before they attend the meeting. This means that management must budget for this time accordingly and not just for the time it takes to attend the actual meeting. The same goes for code reviews. The technical people must not only know the language or technologies used, but must understand how and why they are used with the business. They should review the code before walking into the meeting. QA should work with the programmer to come up with test scenarios, but they had better not depend solely on the programmer, or bad things are going to happen. I can, and will in the future, spend a whole article on QA, so for now I will stop with counting on more than the programmers for test plans.

Last, add a little respect to the whole process, both for the business and for the individuals involved, and you have the making of a sound software development life cycle. Of course, you need good people to carry out these tasks, but I'm assuming we're all good people; we just need to focus a little differently and have our attitudes adjusted slightly once in a while in order to bring our software development processes back from the dead. Remember, it's not how much we produce that's always important, but how well we produce and how pertinent what we produce is to the business.