Giving Up

  1. Posted on April 3, 2008 7:12:PM by Earl Beede to Practicing Earl
  2. humor, requirements, fatigue, Management, Design

When is the right time to give up on a project, a design approach, or a requirement? What factors do you consider in coming to the decision that it is not in the organization's best interest to continue forward with the current approach?

I know that the economically oriented folks will suggest that we look at the net present value discounted over the useful life period minus the initial capitalization and number of pizzas ordered per developer. Sure, that is a fine rational way to do it. However, it has the fatal flaw of relying on human beings to generate the numbers and eat the pizza. In my years of playing with numbers, my conclusion is that the world "playing" is the correct choice. You can come up with just about any result you want.

The economic approach also misses the emotional side of the equation. The project was needed to drive the revenue (or cut the costs) necessary to meet some commitment made to the organization in the annual goal setting exercise. If the project does not deliver, some director or VP will not meet their numbers and that director or VP will look bad. (If we talk about not getting a bonus, then we are back at the fatal flaw of the economic model.) People do not like to look bad so they hang onto the project, the design approach, or the requirement long past its pull date. At which point, they still won't meet their numbers but then the director or VP can blame the poor developer for not living up to the developer's commitment. That the commitment was extracted by force is quickly forgotten.

Don't forget the stigma of being labeled as "negative". If we even suggest that the current approach is not working, the goons from the Corporate Office of Positive Thinking come to pay us a visit. They encourage us to try harder, to work through the challenges, to be a team member and give 1,837% to the effort. Any thing shy of 1,837% is a defeatist attitude and you should probably rethink your career choice.

There often is a lot of pressure not to give up.

So how do you finally make the decision?

The most common answer my exhaustive research (asked a couple of people) has uncovered is (drum roll please) fatigue. As in I am too tired to keep trying.

Case is point is my latest decision to give up on compact fluorescent lighting (CFLs). Yes, I know CFLs are god's gift to lighting and I must be an environmentally insensitive global warming jerk for stopping my use of CFLs. However, I have reached my fatigue point with them. You see, I have this really bad habit of turning of lights when I leave the room (blame my father) and CFLs hate that. They don't like turning on and off. Every time you turn them on and off, they shorten their life span.

So, I found myself leaving lights on (and having the echo of my father yelling at me) or end up paying more for a light bulb that a) didn't last as long as a incandescent and b) put out less light. On top of that, I have a garage full of the damn things waiting to go to the hazardous waste site since you can't throw them away.

I got tired of messing with them so I gave up. Is this the most rational way of making the choice? Maybe not. However, I do think it is the most common way, whether CFLs or software projects. I wish there were a better way but this is the one that seems to work.

Global Warming » Giving Up said:

April 5, 2008 12:39:AM

Pingback from  Global Warming » Giving Up

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl