Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to deal with software development schedule pressure

Matthew Heusser | April 10, 2013
The work is due next month, but you know it won't be done for three months. Now what? A group of programmers and consultants met at a recent software development conference to swap war stories and discuss management and firefighting challenges.

What we're saying-that we can have something in production by the end of the week-makes no sense to them. They want to see the three-year plan. Frankly, until we've delivered, they have no reason to believe it.

Keller: Some people have the thought that they get the commitment to November in order to get it in May. The false-commitment makes sure they get it at all, and they believe it makes the team work really hard.

Drzewiecki: That's schedule pressure as a tool-from a belief that if you don't apply the pressure, the technical team will be lazy. There's a lot of distrust there.

Kaufman: Sometimes the hidden message is to deliver the crappiest piece of software as soon as possible.

Keller: Team members worry about a death march. A few people just can't work longer hours for family reasons. The team often figures out [it] can get it done by sacrificing quality.

Drzewiecki: I've even heard of management specifying a "warranty period" after ship. They expect bug fixing the month after shipping, we'll get nothing else done and that is OK. I did not take that forward, I did not tell the technical teams; it would destroy them to tell them they did not have to take pride in their work.

Quality, Time Squeeze Software Testing, Deployment Schedules

Barcomb: How much planning are you doing to predict how long the fixing will take?

Hajratwala: When we said we'd ship with zero known defects, it turned a few heads. The QA guys like it; they're amazed they don't have to "accept" a buggy story anymore.

Drzewiecki: It's a lot easier to get the QA guys to buy into that when they realize we're not pointing at them. We want them involved and want to improve the quality before it gets to QA.

Barcomb: If that's the policy, how do you deal with defects that are found in production? How do you get people to not "blame" testers? How about shipping buggy earlier and fixing later? Is that acceptable? Would [software consultant] Uncle Bob Martin yell at you?

Hajratwala: Of course. But would you ever take that deal?

Kaufman: You'd lose any credibility with the technical staff [by] asking [it] to do something like that.

Barcomb: It depends on what it is. Gmail was in beta for how long? And people like it. A lot of companies want to be like Gmail, but they don't want to make the investment in quick deployment, rollback and monitoring to make that strategy successful.

Hajratwala: It's also different to develop one feature and roll back if you need to than to develop a pile of stuff in a year and push it all out to production at the same time.


Previous Page  1  2  3  4  Next Page 

Sign up for MIS Asia eNewsletters.