Home > Articles > Programming > Visual Basic

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

The Creature

If your experiences with a prototype lead you to believe there may be scheduling or staffing problems, take action immediately. Don't think you can make up the shortfall by working extra hard.

NOTE

I have worked on only one project that I truly consider a failure. As the deadlines drew near, one important piece of the system was falling farther and farther behind.

The natural reaction for managers at that point is to pile more people on the project. Unfortunately, we had already used up all of the compartmentalized pieces built into the project architecture. Adding more people would only slow down the current developers while they brought the newcomers up to speed. Then we would just end up looking over one another's shoulders while one person did all the typing.

What we should have done was step back and reconsider the parts of the application that were in trouble. We should have redesigned them to make them simpler and more compartmentalized. The dying subsystem should have been gutted and reworked from the ground up. It probably would have taken an extra month or two, but it would have given us a chance of success.

Instead, the project manager and I (the lead developer) were called down to corporate headquarters to meet with the program manager (who we dubbed The Creature). She asked for a status report, and I started to explain what we needed to do to get back on track.

She firmly interrupted, "No. That's not the way it's going to be. We are going to drive a stake in the sand and put in the extra hours to meet our deadlines. I haven't had a project fail on me yet, and I don't intend to now." She went on like that for a couple of minutes.

I started to explain that setting a firm deadline and declaring that we would meet it would only demoralize the developers who had already been putting in some very long weeks. She interrupted again with an instant replay using different management cliches.

That's when I was certain we were doomed. As I expected, the developers were demoralized, updated their resumes, and continued to plug listlessly away at the code—fully expecting to fail. The deadline came and went with us only a little closer to a solution. The program manager was transferred to another part of the company. Eventually, the program wandered out of our control into a development in still another part of the company where it languished.

The project manager and I knew that we could save the project if we were willing to acknowledge the direction the schedule was heading and take action. It would have been painful in the short term but would probably have worked out in the end.

Later, the project manager said he was watching me during the program manager's tirade. He said if I had twitched towards the door, he would have raced me to the parking lot.

  • + Share This
  • 🔖 Save To Your Account