The 7 Steps of Software Development Case Study - Chapter IXHow To Communicate With Users

The 7 Steps of Software Development Case Study - Chapter X

May 23rd, 2007

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
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Project Management

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (4 votes, average: 4.75 out of 5)
Loading ... Loading ...

1 Comment Add your own

  • 1. Jill Galusha  |  April 6th, 2009 at 11:38 am

    Excellent case study for my class Information and Technology Management class (U of Tampa, FL.)

    I assigned students to play roles of each of these players then walked through the case. They loved it.

    Thanks. Always looking for ways to teach my students(business students) the virtues of Systems Development methodologies.
    — Jill Galusha

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities