Guilt-free software development

[softwareNerd]

By softwareNerd from Software Nerd,cross-posted by MetaBlog

Guilt pollutes relationships. At best, it nags at the guilty. It's worse still (for the relationship) if the aggrieved party use guilt as a weapon. The healthy solution is to admit fault, make the appropriate redress, and move on, not forgetting, but neither harping on the guilt.

Early in my career, I was on a software-development team with lots of enthusiasm, but not much knowledge (me too). Our budget was impossibly tight. Everyone on our team worked day and night on it; more than busy, almost frantic. We worked through most nights, snatching a few hours of sleep here and there.

We could not make the schedule. The customer screamed. An experienced project manager would have told us we needed two more months; we asked for 1 month; we got 2 weeks. The client was unhappy; we were guilty. We felt we had let people down and let ourselves down by missing the deadline, even though each of us worked at least 80 hour weeks. We knew we could not get it done in 2 weeks; but, feeling guilty, we gave in.

Two weeks later, though we scrambled and cut corners, we were still not ready. Now, we were guiltier than ever for missing the second impossible deadline. We did not realize we were caught in a typical project-development downward spiral, .

We got an extension of a few days, enough to patch something together just enough that it could stand up to the first few days of QA, before it fell apart. And then, more customer anger, and more guilt... The cycle went on: shorter than practical deadlines, short-cuts, failure, shorter than required deadlines to fix it...

We were down to our Nth extension... we were going to have the project ready in a week (yeah, sure!), when a new, experienced project manager took over. He spent a few days talking to the team and understanding what was going on. Then, a day before the deadline, we were to meet the customers [by now we hated them] to discuss the hand-over to QA.

The new project manager told us that we would not hand over. He refused to let us meet the deadline when we knew we'd taken still more shortcuts. In the meeting, he told the customer that he was sorry that things had gone the way they had but he had taken over the project and he would not deliver to a deadline like this. The customer tried all his "you promised" tricks, but there was no budging.

The surly customer asked how many days of extension we needed this time. "We need 5 weeks!", he answered. You could hear a pin drop; and then, loud protests and threats of cancellation. "If we try to deliver in less than that, we cannot deliver. So, I agree that cancellation would be the only other option", he agreed. "I cannot pretend it is possible in less than 5 weeks.... From what I have seen, I needed 2 months if people were to work normal hours, but the team will do overtime and see that it gets done in 5 weeks. ... I know the previous project manager promised; we can discuss that separately, it does not change what we need to do to succeed..." The conversation went on like that, with not an inch given, unless ones counts the time he said: "Well, let me say this, when I say the 21st, it will be 9am on the 21st... so your team can come in and test right away!"

"I want to add something more... I don't want any misunderstanding... when we deliver the software on the 21st, it will contains bugs."

What! The senior client manager, who'd been on the verge of giving in, almost threw a fit at this remark.

"It will be tested: unit tested, integration tested; but, all software has bugs, and this will have bugs too. Today the software has bugs that ought to have caught; the software we deliver won't have those types of embarrassing bugs.... but, it will have others. We will start work on bugs as soon as you report them, but you should plan to give us 2 more weeks after that, for us to continue to fix them."

"Even after the software goes into production, you will find bugs -- this is something we have to live with; so, we need to plan for it, and deal with it."

Long story short: the project was a great success. Though I was an Objectivist then, this episode concretized the value of not evading reality, and consequently not shouldering guilt for doing so... it's a deadly cycle.

Afterword: The whole idea seems so "duh!" obvious, but I suppose it's the folly of youth. The same project manager also taught me a few other little things:

• History will always repeat itself, unless you do something more than wishful thinking to stop it
  
• Always carry a virtual letter of resignation in your pocket: it's good for you, and good for your employer.
  

Edited October 18, 2007 by softwareNerd

[fatdogs12]

I think that is really a pretty great post. A lot of important points there. I think one thing aside from what you mentioned is the honesty. I think it's super important to just be honest with clients. I know a lot of programmers/web developers undershoot to get business with companies and end up having to try to talk their way out of it, or even worse develop an entire application at a loss to themselves.

Though I've slipped the schedule at my company many times I've found that it's just best to be honest about the situation with them. If you screwed up let them know "Hey I made a miscalculation, it's my fault. It's probably going to take another two weeks to finish".

But in addition to that this is a great concrete example of adhering to reality and the consequences of not doing so