Susan gazed with malice at her baked cod plate. Snuggled up against the filet, two new potatoes and a violently green sprig of broccoli gazed back.
Susan gazed with malice at her baked cod plate. Snuggled up against the filet, two new potatoes and a violently green sprig of broccoli gazed back.
"So, Joe, I understand you've been doing maintenance programming over in accounting for the last two years. This is new development. It's a little different."
Joe added a schmeer of sour cream to his El Grande Burrito de Chorizo. He noted happily that it was leaking a little of that good Monterrey Jack cheese from an improperly folded corner.
"It's a bit different," he agreed, "but we've added several major new features to the accounting system that were almost like completely new projects, so I don't think there'll be much trouble."
Susan thought briefly about ordering a steak knife to cut up her broccoli. She knew it wasn't good to cook all the vitamins out of vegetables, but how many vitamins did you get if they were so raw you couldn't eat them!
"Do you think we need to get the quality assurance people involved now, or should we wait until the coding is a bit further along?"
The bite of refried beans and chorizo that Joe was working on was spicier than most and he had to wash it down with a swallow of that good amber lager.
"Well, I don't see what they'd be doing at the moment. After all, what are they going to test until we have some code written?"
About a month into the coding phase, Bill called Susan into his office. "I've been looking through this book," he said, holding up a copy of his new book, SQL for Dummys. "It's got some really interesting stuff in it."
Susan felt a vague unease at this. Department managers playing with technology are like children playing with matches. You want to say, "No! No! Bad department manager! Put the SQL book down!" But she couldn't say that so she said, "How interesting. Really studying up, eh?"
"Did you know how easy it is to generate reports with this kind of database? You just tell it what fields you want and how to find them and, voila, report."
Yes, Susan had heard something about the reporting capabilities of SQL, and it really was very easy. Maybe she could score a few points for the project team by tossing in a few of these quick kills. "Yes, our new SQL database is very flexible," she said. "What kinds of reports did you have in mind?"
"You know we never really talked much about reporting." Bill continued. "I've been looking into this, and I think that just a few extra reports will be enough to satisfy all of our marketing requirements."
Wait a minute! Marketing requirements! Since when did they have marketing requirements? All they ever had in the past was sales. The department received a lengthy transaction list every day that no one ever used, and some weekly and monthly sales totals that occasionally jumped off the report and appeared in a few memos. What else did they need?
By this time Bill had produced a yellow, legal-size pad with a list of report titles on it. "What we really need is a way to categorize our customers by the products they buy... "
In a project, the key to being General Patton rolling across France in World War II, taking the 3rd Army from victory to victory, rather than being a deer trying desperately to get out of the cross-hairs of a pack of hunters' guns, is always keeping the eventual goal firmly in view and making sure that everyone involved with the project knows exactly how far down the road it is. To do that, you have to make sure that the eventual goal doesn't change and the distance between where you are now and the end of the line doesn't increase.
The SQL for Dummies incident is an example of something called Feature Creep. No, this isn't the title of the late, late movie tonight. It refers to the tendency of projects to increase in scope after the design is complete, the target date is established, and the budget is set. It's the primary way that the distance between where you are and where you want to go increases. Susan let that happen when she added those SQL reports to the system. The word she should have remembered is, "No!". The phrase of the day should have been, "Forget it!". Ok, so that's a bit too abrupt, but a dialogue like the following has much the same effect.
"Yes, we'll have to look into those reporting requirements. I'll add that to our phase two document."
"Phase two? I'd really like to get these in phase one. Our marketing department is going to need them as soon as possible."
"Ok, if we have to, we have to. Fill out this Change Request form and I'll send Mary around to do the analysis and add the material to our design document. When she's done, we'll have to see what effects that'll have on the time line and the budget, and we can go back to senior management and ask for the budget increase. It probably won't push the target date back more than a month or so, but that's just a guess."
"Er ...maybe phase two would be soon enough..."
You can't blame Bill for Feature Creep. He's enthusiastic and trying to get the best system he can for his department. Susan is the one that has to stop it. Most of them are small additions to the project. Still, several small changes add up to one big one and have the same effect, missed target dates and budget overruns. Susan has to realize that, even though she and Bill are working on the same project, they don't have exactly the same agenda. Bill will ultimately be judged on how happy his customers are and how many new customers he can attract. Susan will be judged on whether they were on time and under budget.
Change control form! The truth is that it's more of a Change Suppression Form. It formalizes a simple idea that is otherwise very difficult to get people to understand. Every time you change the specs for a project it becomes a new project and you have to go back and redo all the initial steps: the analysis, the Detail Design, maybe the Business System Design, the time line, and the budget especially. Ordinarily, the mere mention of the Change Control Form and the subsequent procedure is enough to deter the change's sponsor from continuing. If not, then find the analyst and do whatever minor surgery is necessary on the design document, come up with some date and cost estimates and go back to the changes sponsor with the new figures. The end result is that changes to a project that is already underway are reduced to a minimum but not made absolutely impossible, and those that do occur are chalked up to a specific person. About what you want to happen.
Change control also addresses another problem with Feature Creep. The likelihood that it will become Undocumented Feature Creep. Since the project is already in a programming stage, there's a tendency to just program the new stuff and not go back and update the design documents. Having a change control procedure in place that includes updating the design documents will give Susan some ammunition to work with when she tries to retrieve Mary from her new project to do go back and re-do the analysis for the new little pseudopod that the old project has extruded.
The arguments that Susan and Joe used to not involve the Quality Assurance people at the start of the coding phase are similar to the ones that were used to not involve the programming staff during the detail design, i.e. there's nothing for them to do at this stage. And they're wrong for much the same reasons. QA, like programming, has a setup phase that can vary enormously depending on whether the project is a brand new application or one that's just adding a room addition or a garage to an already existing structure.
The main task that the QA person has to perform is setting up The Big Test. Sometimes known as the "regression test" or the "day test", this is a test environment that tries to simulate an entire day's activity for the system. It consists of miniature versions of everything the system does. If the production database consists of 100,000 customers, the regression test database might have ten customers. If there are typically 10,000 transactions a day, there might be 200 in the test test system, but in every way other than volume, the test system is exactly the same as the production system.
It takes time to set this up. The general idea is to throw one of everything into the input hopper in the front of the system and check to see that they all emerge from the final assembly line in back looking exactly as they should. What's one of everything? If there are ten basic transactions, and each of them has four sub-transactions, that's forty cases, but any living, breathing application has bunches of special cases -- sometimes specific to a single customer or product -- that multiply and add to that total. The QA person needs to identify all of those cases, which not only means looking at the detail design, but going back to the unit and interviewing the operations people, and then start building his miniature database. Also, everything has to fit together, all the customers and products in the miniature transaction file have to fit with the customers and products that are on the miniature database. Finally, some batch scripts have to be built to set up the test and to take the place of the communications steps that ordinarily occur.
The result of all this is worth the effort. The unit testing that programmers do on their new code and maintenance changes is useful for eliminating obvious bugs, but it has some major shortcomings. One problem is that errors in one person's program can produce problems in someone else's program, something a unit test, by definition, can never catch, but the Big Test catches easily. Another problem that the Big Test catches is one where a programmer has the wrong idea about something, codes that wrong idea into his program, and then sets up test data to match it. If he thinks that roses are blue and violets are red, he'll code it that way and then set up test data containing blue roses and red violets. The unit test of his program will work perfectly, and the Big Test will fail miserably. Finally the most important problem the Big Test solves is the tendency to fix one thing and break something else while you're doing it -- a mistake that's easy to make. Without the Big Test, the programmer will tend to fix the known problem, test the fix, install it in production, and then find out the hard way that something else is broken.