The 7 Steps of Software Development Case Study - Chapter VII

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding

Chapter VII: Testing

Now it’s time to see if the program does what it’s supposed to do. It should either work or not work, right?

Pat, the QA manager, takes the internal test version CD from Joe and throws it on her perpetually messy desk. After a day or two, she remembers to hand it to Tim, a QA tester. The disc has been damaged, probably due to a drink spill, and won’t load the program but Tim is too busy betting on sports over the Internet to get a new one from Joe. After a couple of days, he tells Pat that the product is too defective to test effectively.

Pat tells Brian that the new program is “untestable”. Joe and the team get another visit from angry Brian who cuts into them again with a barrage of insults. Joe, very frustrated and, attempting to redeem himself, prepares new sets of install CDs directly from the source code repository while Brian watches and delivers them directly to Tim with Brian and Pat in tow. Joe makes sure that it installs on the QA systems and runs correctly. Tim sighs, knowing he doesn’t have an easy out this time around. But to help cover his tracks, he says, “This version looks a lot different than the other one. Do you have a list of changes you made for the new compile?” Joe says, “What are you talking about? This version is the one you had before.”

Tim’s testing doesn’t find any major defects but he creates a long punch list of trivial issues. Brian and Pat call a meeting to discuss the defects. Brian seizes on the number of issues and says, “Tim was right. That original version you gave him must have had far too many defects to ship. You shouldn’t have given it to him in the first place since you should have known how bad it was. It looks like you were trying to pull a fast one to buy yourself a little more time.” Joe, who’s had enough at this point, shouts back, “Bull[explicative]! He never even tested it!” and gets in a heated argument with Brian and Pat about the defects and Tim. The next day, Joe is given a third formal HR reprimand for “insubordination”.

Joe is in even deeper kimchee after testing and peers like Tim are pouncing on his vulnerability. It’s not going to be pretty. In Chapter VIII: Deployment, the program goes out into the world.

Following Chapters

» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter VI

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design

Chapter VI: Coding

At this point in the project, coding begins. What could possibly go wrong … go wrong … go wrong …

A week and a half later Mary is back in the office and, after the usual delay to schedule a meeting with her, she looks at Joe’s in-development work. She goes ballistic because what’s been done isn’t exactly what she wanted. She points to several features and says that they’re completely unnecessary. She complains that the colors are all wrong. She goes on to say that the program is lacking an important function that’s a “must have” to get the product to sell in the industry. She complains to Stan and Phil about it and they question Brian. Brian tells them that Joe is a “loose cannon” who did not follow proper procedures and that he’ll reprimand him for it.

Brian then delivers another verbal beating to the team, berating them for not being able to follow simple requirements. Later that day, Joe is called to HR and presented with a formal reprimand document for “not following established procedures”. Brian follows this up the next day during the monthly IT staff meeting by bringing up the reprimand as an example of what not to do.

Frustration mounts as Mary refuses to sign off on revised requirements and design documents that Joe created because they’re “incomplete”. She presents a large list of changes that she believes are needed. Brian continues to insist that the team code the application and complains that the project is falling behind schedule although no formal schedule has been set to the team’s knowledge, especially one that incorporated Mary’s many changes. After a painfully long meeting with Stan, Brian, and Mary plus Joe and the development team, she finally signs off on the design while letting everyone know how unhappy she is about the direction the product is taking. In the same meeting, the slow speed of the development work is mentioned and to answer this, an unrealistic project timeline is presented by Brian. Joe and the team are shocked but they agree to it in order to avoid yet another verbal assault.

The team pulls themselves together in spite of all the pressure and codes like crazy, working extra hours and weekends. Brian even does his part by approving overtime for the contractors for a few weeks until accounting complains and he limits them to 40 hours a week again. He also stays out of the team’s way by not being around more than regular office hours and then goes on vacation, much to the team’s relief. The team manages to deliver an internal test version of the program on the target date designated in the timeline Brian had published. This date is the same as the first day of the national sales meeting, oddly enough. The team is happy for once.

However, their joy is short-lived because Brian, who returns the next day from a week of vacation in Europe, is livid. He tells Joe that today is supposed to be the ship date, not the testing release date. He says that the product had to be released at the start of the national sales conference. When Joe shows him a copy of the timeline tacked up on his cubicle wall that clearly showed the current date as the testing release date, Brian says, “It figures an idiot like you would be working from the wrong time schedule. Don’t tell me you didn’t get the revised copy I sent out either. You have to be the most incompetent lead I’ve ever seen!” Brian calls up Stan and has Joe apologize personally for the delay. He also writes up another formal reprimand for “failure to complete assigned work in a timely manner” and HR presents it to Joe.

Things aren’t looking too good for Joe. He better have his resume ready. In Chapter VII: Testing, we will see how the hastily assembled program does when it’s put to the test.

Following Chapters

» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter V

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis

Chapter V: Design

At this point in the project, detailed development plans should be made and a good foundation for coding should be in place in the form of a good design. Let’s see what happens.

With Mary not around and under pressure from Brian to get started anyway, Joe puts together preliminary versions of the formal requirements and technical design documents. Plus he and his team also develop some prototype screens to show her when she returns from her conference next week. He is unsure about the direction to take on some of it due to the rather sketchy information but he feels that having some visible choices will help her decide what’s needed and what is not really required. Fortunately, the team Brian assembled for him are competent programmers although they lack important industry knowledge.

Brian drops by with Stan and Phil in tow the following Monday and they ask how the project is going. Joe shows them the screen prototypes. After a cursory glance, Stan says, “This is great progress. We’ll have the product ready to ship in no time.” as Phil nods in agreement. Joe explains that these are simple, non-functional, storyboarded mock-ups and that he’s awaiting Mary’s further input on the design before proceeding much further. Stan and Phil look disappointed and confused while Brian’s face turns red with embarrassment and anger. Phil says, “It doesn’t look like you have much more than what Mary showed us 6 weeks ago. What’s the story here Brian?” Brian says, “I’m surprised about this too Phil but I’m going to check into it!”

After Stan and Phil leave, Brian explodes. In a huff, he pulls all the developers on Joe’s team into a meeting room. He questions the team’s competence as programmers. He calls Joe lazy and a poor leader. He finishes up by telling the team, “Stop wasting [explicative] time playing around with [explicative] fluff and just code the [explicative] program! If you can’t do it you can rest assured that I can and will find somebody who can!”

After Joe and the team recover from their verbal beating, they start turning the rough prototypes into the actual application although there are many questions about the design remaining. Brian is happy to see that the team is coding and, a couple of days later, he tells Joe, “See what you can do if I motivate you properly.” He tells Joe not to get bogged down in the requirements and design thing. He emphasizes how important the project is and that Stan and Phil don’t want any further delays. He says that he’ll go ahead and take responsibility for signing off on the design since Mary won’t be available for at least another week since she apparently caught ‘a bug’ during her business trip.

You can bet nobody went home happy that day. In Chapter VI: Coding, we get to the heart of the work and Mary returns to the office.

Following Chapters

» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

1 comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter IV

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis

Chapter IV: Specification and Requirement Analysis

In this phase, Joe, as the project lead, should be refining the requirements and laying out the game plan for the development to come. What happens isn’t quite that.

After the meeting with Mary, Joe has a lot of questions about her off-the-wall scribbling and the vague magazine article. He even questions the practicality of the project as he begins to analyze the information early the next week. He tries to bring this up with Brian but all he wants to know why the team, a hastily assembled group of new hires and contractors Joe didn’t even interview, isn’t coding the project yet. He tells Joe that Mary told him she had given him complete requirements just before she left and that should be all he needs. Brian says, “The requirements are in the can, done, fin-eat-oo, don’t worry about them.”

Joe starts to protest but Brian blows off Joe’s complaints about the state of the requirements again and makes it clear once again that the project has top priority. He tells Joe, “Mary is an idea person, not a detail person like you. She’s going to be out of the office for the next 10 days so why don’t you show a little initiative and write up the detailed requirements ASAP yourself? She wouldn’t know what you were talking about anyway. Take the bull by the horns and get it done! You’re a ‘can do’ kind of person, right? I only want ‘can do’ people on my team.”

Joe agrees that he is a ‘can do’ person and tells Brian that he’ll get the requirements wrapped up and hold any questions until Mary returns. Brian says, “OK, great, just get the ball rolling.”

It doesn’t look like Brian thinks much about having a lot of design work. He’s interesting in lines of code. This heats up even more in Chapter V: Design

Following Chapters

» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter III

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters

Chapter III: Preliminary Investigation and Analysis

Remember, this phase should involve extracting the requirements from project sponsors and management gauging the feasibility of the the project. Let’s see what happens at our fictional mortgage software company during this step.

Mary, the Director of Marketing at EzSoftiMortgageCo, reads a trade magazine article and decides the company needs a hot new product like the one mentioned there. Does it matter that a lot of it isn’t practical or applicable to the product lines the company currently sells? Of course not! All that matters to her is that it will create some buzz at upcoming trade shows. She whips together some rough sales projection numbers and sells the idea to her boss, Stan, the VP of Sales and Marketing.

A couple of weekends later there is an executive management retreat strategy meeting. Stan and Mary give a quick presentation that relies heavily on the rough pie-in-the-sky potential sales numbers that Mary had essentially made up. Stan tells them that this is a “must have ASAP” product that has to be ready by a major trade show coming up in 6 months and preferably by the company’s national sales meeting in a little over 4 months. Phil, the CEO, is very excited about the potentially high revenue shown in the briefing. He orders Brian, the Director of Software Development, to get the project started right away.

After returning from the retreat, Brian pulls Joe, a development team lead, off the project he’s been leading for about 4 months and tells him to get with Mary about a new product ASAP. Joe protests the move by telling Brian that the current project, a key upgrade to the company’s core program suite, is nearly complete and he has the most knowledge about that complex product. Brian explains that he’s giving that project to one of the junior developers to build up their team lead experience. He tells Joe, “I want my best development lead on this new and important project. You are the best, aren’t you? That old project is on autopilot anyway, a trained monkey could handle it. Stan and Phil want this new program ASAP and are watching it closely. A high visibility project like this will give your career here quite a boost.”

When Joe tries to schedule a requirements meeting he discovers that Mary is very busy. It takes almost 2 weeks to schedule a meeting with her because she keeps canceling meetings, ignoring emails and voice messages, and is never in her office. Finally, tired of the run around, Joe asks Brian to help get a meeting set up. After complaining about Joe not taking any initiative, he grudgingly gets a meeting set up with her for about 15 minutes late on a Friday afternoon. She quickly runs through what she wants in rather general terms and then hands Joe her ideas scribbled on a couple of legal pad sheets and a poor photocopy of the article. But, more important to her, she also has images for branding the product’s splash screen and about box and a color scheme. She tells Joe, “Make sure that you use my pictures and colors in the program because that’s what I’ll be ‘sneak peak’ promoting next week at an industry conference in Jamaica next week.”

It doesn’t look like a lot of investigation and analysis was actually done in this step. Let’s see what happens when Joe starts working out the details in Chapter IV: Requirement Analysis

Following Chapters

» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 23rd, 2007