Posts filed under 'Project Management'

The 7 Steps of Software Development Case Study - Chapter X

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
» Chapter VIII: Deployment
» Chapter IX: Maintenance

Chapter X: Aftermath and Comments

Here’s what happened to our characters in the 6 to 12 months after the end of the project. I’ll also offer my final observations and comments.

Joe, our development lead, finds a new job after a couple of months out of work. He has become even more cautious and introverted and avoids taking any initiative or leadership in his work.
.
.
.
.
.
Brian, the Director of Software Development at EzSoftiMortgageCo and frequent F-bomb dropper, doesn’t get his promotion to CIO as he thought he would. This job goes to an outside hire. A few months later, he takes a CIO job with another company, much to the relief of Phil, the CEO, and the new CIO who were preparing to fire him since his bullying ways had caused considerable turnover in the software development team.
.
.
.
.
Speaking of Phil, the CEO, he sells the company to a large real estate and banking conglomerate about 9 months after the release of the failed product. He makes a multi-million dollar profit from the deal.
.
.
.
.
.
.
Most of the IT staff is laid off as being redundant a few months after the buy out, including the testing team of Pat and Tim.
.
.
.
.
.
Mary, the Director of Marketing, goes into a leadership position in the marketing department of the new company and fits right in. Phil’s recommendation seals the deal for her to make this move.

Our two sales champs, Stan and Bob, also make the move to the new company’s sales team on Phil’s recommendation.
.
.
.
As for the product that they worked so hard to develop, it is dropped from the company product line during the acquisition.

My Comments

Well, that’s our tale. It is kind of a worse case scenario but it isn’t that uncommon of an experience for many who work developing software. Many parts of it probably felt like, “Been there, done that” to you. Let’s look at a few aspects of the story.

Joe, what can we learn from him? His situation comes about, in part, because he isn’t a good communicator and that he doesn’t push back enough on unreasonable demands and bullying until it’s too late. This is unfortunately a problem for many skilled software developers when faced with people with more forceful personalities, like just about everyone else in our story. Learning how to push back and deal with office politics is an important skill for all programmers to learn. Learning how to deal with a bully of a manager is also important.

Brian is an example of a manager who uses yelling, subterfuge, and bullying to control people under him. He’s perhaps taken to extreme in this story since he is an amalgam of the bad aspects of about 8 or so managers I’ve either worked for or people I know have worked for. However, managers that toxic do exist out there so you, as a software developer, have to be prepared to deal with these walking, talking, versions of Bill Lumburgh or Dilbert’s boss.

In the testing team of Pat and Tim, we see another negative aspect in software development, the unintentional and intentional sabotage of fellow employees who’re considered weak or rivals. In a toxic corporate environment, such people can make your troubles worse if you let them.

The rest of the characters are pretty typical corporate types you’re likely to encounter in any company, the demanding marketing manager, hard charging but somewhat clueless salespersons, and out-of-touch executive management. Knowing how to deal with them is important too.

Process-wise, the company had several problems. Most of these center around poor communication. For example, the problems Joe had with scheduling meetings with Mary. Ideally, communication would have been open enough to overcome the design problems a lot earlier. The less said about Brian’s communication technique the better, it simply isn’t the way an effective manager communicates with their subordinates.

Another problem you might have noticed was that testing did not get involved early in project but at the very end. One of faults I see in the whole 7 steps paradigm is that testing comes after coding. In practice, I’ve found incremental testing of incremental releases as coding continues to be more effective in weeding out bugs and producing a better end product.

Your Comments

If you have any comments you would like to make on this story, please make them here or use the contact me menu button to send me an email. Thanks for reading and I hope you enjoyed the story.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

1 comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter IX

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
» Chapter VIII: Deployment

Chapter IX: Maintenance

This step is concerned with maintaining the existing program by fixing any bugs and enhancing the software. In our case, the misery continues.

Joe is hardly surprised about a week after the product ships to get a call to report immediately to HR when he arrives one morning. It seems that the company has instituted a new program called ‘forced ranking‘ and it seems that Brian has rated him as being a ‘C’ player. He signs a few documents and is escorted out the door by a security guard. His belongings from his desk are shipped to him a week later with several things missing.

Brian reinforces the point with all of his employees in a meeting by telling them, “If you’re a [explicative]-up like Joe you’ll be gone too!” The already low department morale sinks lower.

Hoping to address the perceived weaknesses in the original release, Mary and Brian work up a spec for a 1.1 release. Unfortunately, all of the contractors who worked on the project have left and the two remaining junior programmers who were on the project are working feverishly on the significant problems in the company’s core product. No one on the software development team wants to take on a ‘cursed’ project and find ways to avoid taking ownership of it. The enhancements are shelved and the product languishes and becomes even more unpopular in the company and with customers.

It doesn’t look like the program has much of a future. Next we’ll take a look a few months down the road and see what’s happened and I’ll offer my closing comments in Chapter X: Aftermath and Comments.

Following Chapters

» Chapter X: Aftermath and Comments

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter VIII

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

Chapter VIII: Deployment

Now it’s time for the program to leave the nest and find its place in the world.

Bob, the National Sales Manager, has a large nationwide client that wants the new product “NOW!” even though it’s still in testing and not due for full release for another 10-14 days. Since the commission from this sale will be huge, he talks to his boss, Stan, into getting the new product to them ahead of time. Stan says “Do what you have to do to make the sale.” Bob goes to his sports betting pal, Tim in QA, and takes an install CD from the test lab and delivers it to his very important customer.

However, Joe doesn’t know this has happened until a rep in the tech support group calls him and asks why the new product won’t install on the customer’s system. Joe says that the product shouldn’t even be shipping yet and calls the customer himself and discovers what happened. It turns out that Bob gave the customer the original defective test CD. A good replacement is sent but the customer has cooled on the product and they don’t place as big an order as had been anticipated. Bob blames IT in general and Joe specifically for the canceled orders.

Finally, the actual product is released and it gets a rather tepid response in the marketplace and from within the company. Industry blogs and trade magazines call it a weak “me too” product. Mary hates it and says that it wasn’t what she had specified. Bob warns his salespeople to be careful selling it until all of the bugs are worked if they want to keep their customers happy. Stan and Phil question Brian on why the project went so badly and why the upgrade to the key company product, Joe’s previous product, is having so many problems. Brian makes it clear what the connection is between the two (Joe) and promises to take care of him and any other non-productive and incompetent people in his department.

At last, it’s time for the program to go into maintenance mode and for the department to do a post-mortum on how well the project went and to make any corrections. Can you guess who will get corrected? Read about it in Chapter IX: Maintenance.

Following Chapters

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

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

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

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

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

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

Next Posts Previous Posts


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives