EA Another element of XP that is perhaps a little controversial—and it’s not really about coding and to me it’s one of those mythical beasts—is the 40-hour workweek. I certainly do believe that programmers should not be working 80-hour weeks all the time, but management, which usually means the CFO, loves working programmers for 80-hour weeks, week in and week out. You can’t be productive that way in the long term.

BC No, not at all. But software development is a series of sprints, and the marathon is really only a composition of sprints.

EA Yes, it’s a series of sprints, but why is there never a rest break between the sprints? How do you convince management that they have to give you some time to chill out?

BC By writing great software. We’ve been able to structure the environment here because enough of us have a track record of writing great software that management knows to leave us alone.

^{You’ve also got to be} There are som e g uidelines willing to schedule yourself.

_{If you want to get to the} that improve the code, but point where you have some my question is, how much flexibility to pursue things, _{you need to be as transpar-} does this actually help you ent and as honest about structure the code...? your schedules as possible, because—just like Wall ^{Steve Bourne} Street—more than actually wanting results of a certain level, management really wants predictability.

They want to know if it’s going to deliver six months later than you thought it was going to deliver. In the abstract, it’s not like that six months, in terms of the time to market, is going to cost us the business. In some cases maybe it would, but in most cases it’s not going to. If I went to a customer and promised this is going to be finished in June, and now it’s not going to be finished until December, then you’ve impacted the relationship with that customer. But as long as you’re predictable, I think you can get that time for yourself.

In terms of how you convince management, you don’t treat scheduling as a kind of tedious exercise, and you don’t tell management what they want to hear. A lot of engineers think that the best thing to do is commit to the most aggressive date possible. No, don’t do that. You should commit to a date that makes sense and try as hard as you can to meet that date. As soon as you know you’re

not going to meet that date, you want to make that clear and slip the schedule accordingly. If you do that, then I think you can get the time.

SB I don’t know if it’s in the Extreme Programming dictionary or not, but the simple version of this is don’t commit to the date until you’ve written the prototype, because you don’t really know what you’re doing until you’ve got something you know you can build. Even then, even if you do commit to the date, it’s important to manage expectations after that to make sure that if the date is going to change, you say the date is going to change.

BC Steve, you hit on a very important point, which is
that the transparency of schedule actually interrelates
with your development methodology. If you use a
waterfall methodology, you’re much more likely to slip
because there’s so much that’s unforeseen. When you’re
using rapid prototyping,
and you’ve got an idea of
what the problem space is,
you’re much more likely to
come up with a schedule
that you’re going to hit.
EA As I understand it, XP
uses rapid prototyping, but
it’s called “spike solutions.”
I’m also reminded of my
past where we always said,
“Prototypes are great...and
they always get shipped to
customers.”

BC Which is the other half of the coin. When you do

rapid prototyping, management sees a prototype and gets very excited.

EA They say, “Good, it’s working. Sell it.”

BC Or they say, “You showed me a prototype eight months ago. What have you been doing for the last eight months?” You say, “Well, I’ve been doing the 90 percent of the project that you don’t necessarily care about because it doesn’t impact the prototype that you see, but it does impact the quality of the product you deliver.”

Management needs to realize that when they see a prototype they still need to trust the schedule that they’re getting out of the engineer. They should view the prototype as a way of knowing that they’re on the right track and as something that they can talk about with customers. EA I think you’re assuming a pretty enlightened management. Unfortunately, that has not been my experience in most of the real world.