ADAM SANDERSON: All right folks.
This is Unreasonable Estimates and
Improbable Goals. My name's Adam Sanderson.
I'm a full stack developer at LiquidPlanner.
I've been there for about six, nearly
seven years, working on Rails, databases,
like, front end, back end. You name it.
If you want to, you can find me on
GitHub. Twitter. These slides are gonna be on Speaker
Deck. It's all under Adam Sanderson. That makes it
easy. But more awkward, I write code, or I
write about code on monkeyandcrow dot com. If you
like the talks about, like, reading and learning about
Rails, I'm actually writing a series called reading Rails.
So go check that out if that's what you're
in to. And hey, it's RailsConf. You probably are.
So, like I said, I work for LiquidPlanner. We
make online project management software. Probably the most interesting
thing for you guys is that we do probabilistic
scheduling, which is pretty awesome. So if that sounds
kind of cool, like everyone else here, we're hiring.
And I need somebody to come help me build
new stuff. So really, if you're in Seattle, let
me know.
So, you can't really work on project management software
without thinking about the work of work. Specifically, I'm
talking about estimating projects, finding the hidden costs involved
in those, and then dealing with deadlines. Sounds like
fun, right? Sounds like life.
All right. How hard would it be? I get
asked this question all the time. People come up
to me, and they say, hey Adam, how hard
would it be? How hard would it be to
change all of our buttons from red to blue?
How hard would it be to implement a new,
like, class of user? How hard would it be
to implement email integration? What should I do?
Clarify. Before I tell somebody how hard it would
be - and, pro tip, they don't care how
hard you gotta hit the keyboard. What they're actually
asking is, how long is it gonna take you
to get this done? Before you tell them, clarify.
Make sure you know what they want. Make sure
that what's in your head is what's in their
head. Because a lot of times when people come
to us, developers have a very specific vocabulary. Things
that we think mean one thing mean a different
thing to somebody in sales, or marketing, or QA
or support.
So make sure that you know what they mean
when they say, hey, how hard would it be
to integrate email integration? Does that mean sending emails
out of our system? Does it mean receiving emails
from someone else? Does that mean a plugin for
like Outlook or Gmail? If you don't clarify up
front, you could spend a lot of time wandering
off into the woods, and when you come back
with your amazing feature, they're gonna look at it
and be like, what? What is this? And you'll
have just wasted, like, an hour. A day. A
week. Oh, that's gonna suck. So clarify.
Next, clarify. Ah. Again. So. Look, you know what
you're doing, now you gotta figure out why you're
doing it. Ask them. Hey, why do you need
to me to integrate email integration? Maybe they turn
around and they say, well, look, we've been getting
a lot of customers sending us screenshots and it'd
be nice to just be able to email those
into the system. Does a better, does a solution
already exist? If it does, you might be able
to point them towards that. And a bonus for
you, now you don't have to do anything.
Maybe they turn around and they say, yeah, I
know that that exists. But it's kind of a
pain to use. Well, now maybe you've found that
there's a better approach to solving their problem. Maybe
you just need to fix existing functionality. People come
to us, all the time, with prescriptions for solutions
to problems. It's really useful for us to take
a step back, and before we say, yeah, I'm
gonna do that, to say, wait, why do you
need me to do that? Maybe you can help
them come to a better solution. And, by doing
this, you're gonna get a better idea of what
you need to do.
All right. Once you know the what and you
know the why, it's time to start thinking about
estimating how hard it's gonna be. How long it's
gonna take you. I want you to think about
the major pieces of work that you're gonna need
to do. Imagine the project and, instead of thinking
about it in their terms, in terms of the
domain of the person asking you, think about it
in terms of what you have to do.
Is it gonna require a lot of database work?
Well, think about the tables. Is it gonna require
a lot of work in Rails? Think about your
models, your views, your controllers. Is it gonna require
a lot of front end work? Well, think about
the different components on the screen. Break these large
tasks down into smaller things, and write it down.
You're gonna need to refer back to this later
anyways. This is the stuff that you need to
do in order to, like, service their request.
Next, sometimes it could be overwhelming to get some
of these asks from people. You'll find that they
have so many, like, business rules that they want,
they've got so many little details that they want
to impart upon you. It can make it really
hard for you to see the forest for the
trees. Step back for a moment. Try and find
unifying principles in what they're asking for. Is there
some model that you can make, in your head,
that explains what they're looking for? It doesn't have
to be perfect. It's just gotta be enough so
that you understand what direction to be going in.
Again, write this stuff down. You'll need it later.
All right. You've broken stuff down. You've grouped stuff
back up. It's now in a stage where you
can sort of wrap your head around it. Think
about other things that you've done. Have you done
anything like this before? One of the unique things
about our profession is that we tend not to
do the same thing twice, and if we do,
we're kind of doing it wrong. So, if you
can, think about similar things. But maybe you haven't.
Turn and ask one of the other developers in
your company. Maybe they've worked on this code before.
Maybe they've dealt with this type of issue before.
They can help you get a better estimate.
And on top of that, if they're doing their
job right, maybe they'll ask you what it is
that you're trying to do, and they'll ask you
why. This is awesome, because it turns you around
and makes you be the person who is asking
you for work. It's really helpful for clarifying what
you've got to do.
Now, there are dozens of different methodologies. Different approaches.
Different sciences of estimation. Here's what I want you
to do. Make a guess. That's it. I know.
You could play planning poker. You could do all
number of things. But, just make a guess. Here.
I'm gonna make it flash. There. Isn't that awesome?
Seriously. Look, an estimate's just an informed guess. A
lot of times, we put way too much value
on an estimate. It's OK for you to be
wrong and it's OK for you to be uncertain.
In fact, if you're not uncertain, you're probably wrong.
I want you to quantify that uncertainty. Embrace it.
Are there things that you're being asked to do
that you don't know how they're gonna spa- like,
turn out? Maybe, like, you've got to load a
whole of data into the database and you're not
sure if it's gonna handle that. Maybe you've got
to make some, like, flippy clicky thing that's gonna
be, like, really hard to implement in Internet Explorer
8. Do you know how that's gonna work? Maybe
it will. Maybe it won't.
Raise these things up. Let other people know. If
they're asking you to do this work, say, you
know, I'm not really sure about how this is
gonna impact our database. I'm not really sure whether
IE 8's gonna support this user interaction you're asking
for. This is helpful, because it gives the other
person a better understanding of what you need to
be doing.
Now, next, play a spread. Tell them a story.
If everything goes well, I think that this might
be done in a week. If I need to
denormalize my database, if I need to do something
really crazy to get this supported cross-browser, this could
take me four weeks. Look, it's a lot easier
for you to hit an estimate, a range, than
it is for you to give them one hard
number. So that's great for us. But it's also
good for the person asking you to do the
work. Because you're giving them a story about the
future. You're telling them useful information about how this
could play out. And if they've got that information,
they can start making better, better use of that.
They can plan better based on that. And it
starts a better dialogue between you.
But you're not done there. You've got to deal
with this uncertainty. Nobody likes to get bad news.
Nobody likes to find out that the project is
doomed. But you know when they like to hear
that? Never. OK. Do you know when they'll tolerate
it? They'll tolerate it right at the very beginning.
You know when they won't tolerate it? In the
eleventh hour.
Oh, man. Are you gonna be ever so happy
when your fellow developer says, hey, guys, I know
we're gonna ship, but I just checked the clicky
flippy thing in IE-8, and it doesn't work.
Wait, we're supposed to ship when?
Nobody wants to find out that the uncertainty got
left to the end. So do it first. It's
really hard to do this, but deal with uncertainty
up front. That way, when you find out that
something's going to take a long time, you can
communicate that back to people, and you guys can
adjust your plans to accommodate that.
I know. We always want to do the fun
things first. I want to like, jump in and
do the stuff that I know really well first,
because I feel like I'm making progress. That's a
great way to set yourself up for failure later.
Now, doing that alone isn't enough.
You remember that estimate? Change it. Change it continuously.
As you learn new things, as you figure out
the uncertain things, and as you make progress, circle
back and tell anybody who depends on you how
long this is gonna take. Give them your vision
of the future. Give them your mental model of
what the risks are. Give them the understanding that
you have, right now, about what you think is
gonna happen.
Communicate often.
All right. Let's talk about the Dark Arts of
project management, for a moment. Look, you know what
you're doing. You know why you're doing it. You've
got an estimate and now. Oh. Shoot.
We can get screwed, as developers. We think that
we're all logical. That we're sane. Now. This ever
happen to you? It happens to me all the
time. Somebody comes up to me and they say,
hey, Adam, how long's it gonna take? And I
say, it's gonna take about three weeks. And they
say, look, we need this done really quickly. Could
you maybe do it in one? And I say.
Well. Oh. How about two weeks?
I thought that I was just being nice. I
thought that I was just splitting the difference, right.
Wrong. I just screwed myself.
It's natural for people to haggle. But you don't
win when people are estima- or bargaining over estimates.
Look, you're estimate is your best understanding of what
the future holds. What made it go from three
weeks to two weeks? How did you suddenly manage
to shave off a whole week of work in
five seconds? Cause I want to know. I need
to be able to do that later, so you
come up and you tell me.
No, look, you can't negotiate time. But you can
negotiate features. And as you learn more about the
project, you can re-estimate. Moral of this story, don't
give people estimates that you think are gonna make
them happy. Give them estimates that you think are
true.
If they keep badgering you about it, point it
out. Say, hey, look, I know what you're doing
here. I see what you're doing. Estimation bargaining. It's
not gonna work. Not only is it not gonna
work for me, it's not gonna work for you.
If you give into this kind of thing, you're
actually setting up not just yourself for trouble but
your team. The people who rely on you. And,
whether or not the person asking you to do
the work knows it, you're setting them up for
failure as well. Because they depend on that estimate
that you just gave them.
So, you know what you're doing. You know why
you're doing it. You've got an estimate. You defended
it. Maybe you shouldn't do it at all. There
are hidden costs involved in everything. Like complexity costs.
Look, some features that we build incur future, incur
costs on all the future work that we do.
For instance, if you build a new RESTful API,
great idea. If you build a new, like, axis
controls, you're just dropping in can-can. If you build,
like, a new mo- native mobile client. Yeah. You're
not done there. From now on, every new feature
that you implement has to take those old features
into account. So what you just did is you
made it so that your future work, future work,
is gonna hate past you.
You're just incurring new costs for the future. So
watch out for these cost-cutting concerns. they can really
bite us sometimes.
Now, there are ways to do this that are
gonna cut down on those costs. You can never
get rid of them entirely. But, if you want
to, do the extra engineering up front, factor that
into your original estimate. Let the people know that
you're gonna need a little bit more time.
What about operational costs? Look, are you introducing new
moving parts? You're gonna build a new job queue.
You're gonna throw resq and redis in place. They're
awesome tech. But guess what? They're costly.
How are you gonna test this in production server?
How are you gonna monitor it? How are you
gonna deploy this? How are you gonna make sure
that it's running every time you spin up a
new server?
It's not necessarily hard. But it does take time.
And once you've done it, it still takes time.
And you know what? When resq goes down, who
are they gonna call? They're gonna call you. You're
the one that put it in place, right. So
dealing with that is gonna take more time out
of what you consider to be your budget for
developing.
Support costs. These are awesome. There are a lot
of things that we can do as developers that
are just really easy. We can knock out a
feature in like ten minutes. The downside? Nobody understands
how that feature works.
So what if your users don't get it? Like,
you built this awesome thing, and they've got no
clue what it does. Who are they gonna talk
to? Well, if you've got one, they're gonna talk
to your support team. I hope your support team
understands - your support team doesn't understand it. OK.
Awesome. Your support team's now talking to you.
And that takes time that you're gonna be not
able to develop in. What if your business, as
a whole, doesn't get it? Meetings. That's what. And
you know what meetings mean? It's not just your
time that's being used up then, it's the entire
company. Everyone around that table? You're sinking more and
more costs into this.
So, again, you can combat some of this, but
go back, update those estimates, to factor this in.
What about opportunity costs? Slightly different thing. But think
about this. You can really only do one thing
at a time. So what's the highest priority thing
for you to be doing right now? What's the
highest priority thing for your team? For your business
as a whole? Because, whatever you're doing now is
excluding every other feature that you could be working
on right now.
Think about it. Prioritize all the things that you
would like to be doing. All the things that
you know you should be doing. Make sure that
this is actually the most important thing. Not just
the most immediate thing that you need to deal
with.
Look, I'm not saying don't do anything, but weigh
the costs. Understand them. Recognize them. Everything that we
do as developers costs us down the road. Choose
which ones you're willing to pay.
All right. More Dark Arts, cause I love these.
This one's the most insidious. This one trips us
up as developers, because we've got egos, and it's
really easy to manipulate us. This happen to you?
Somebody comes up to you, they say, hey, how
long's it gonna take? And you say, I don't
know, about a week? And they say, really? Oh,
and they look so disappointed. And then they say,
I thought you were smarter than that.
Wow. That hurts. Then, it's like, kicking you when
you're down. They say, oh, I'll go ask her.
I'll go ask the intern. She seems pretty smart.
Ah. Even worse. You know what happens next? I
don't know about you. But me? I start begging
to do the work. I'm like, you know what?
Did I say a week? I meant maybe, like,
three days.
Whoa, stop going towards the intern. One day? I'll
have it to you by noon.
Fuck.
Aw. Don't let your ego get you into trouble.
Stand by those estimates. Really, the best thing that
we can be as developers, in this case, is
have a little humility. And if you see somebody
trying to do this to you, call their bluff.
Like, they're not really gonna go to the intern.
Well, they might. And it might be a learning
experience for everyone.
But name this. Say, I know what you're doing
there. It's not gonna work on me. Stand up
for yourself. And if you can't, find a new
job.
All right. Deadlines. Like, I've got one coming up
in eleven minutes.
Deadlines come in all forms. They come in a
spectrum. From soft deadlines to hard deadlines. Soft deadlines
are things like goals. They're things we would like
to achieve. For instance, we would like to ship
this by the end of the week. We would
like to get this out by, I don't know,
this next conference. Hey, we're gonna try to get
this out for the customer by Q1.
Hard deadlines are things like, RailsConf. For me, anyways.
Can you imagine, RubyCentral sending out an email. They
say, hey guys, funny story. Adam didn't do his
slides, so we're postponing RubyConf by, like, a week.
Just change your reservations.
Yeah. I'm not DHH, so I can't get away
with that.
It's a hard deadline. So when hard deadlines come
up. Actually, when all deadlines come up, what do
we do? You gotta deal with it. Ignoring it's
not gonna work, and panicking also doesn't work. So,
we've really got four options. The first two are
ones that we as developers think that we really
like, and the second two are ones that managers
think that they really like. Nobody really likes any
of these options, when you get down to it.
But, if it's a soft deadline, if it's just
a goal, you guys can ship late. You can
miss. Maybe. It's probably not the end of the
world. Don't do this all the time, cause you're
gonna look like an idiot. But recognize. Weigh the
balance, weigh the thingies that you've gotta weigh. I
don't know.
Yeah. This talk is about work. Not about how
to give a good talk.
Rad. So, yeah. Sometimes you can ship late. Of
course, there are hard deadlines, right. There are things
like RubyConf. And I can't miss this deadline. If
I did, we would all be standing here and
I would be stammering like I was. So what
else can we do?
Well, we can cut scope. We can cut features.
Like, honestly, prioritize the things that you've gotta do.
Figure out what you can get done by the
deadline. Cut the rest.
For instance, I illustrated like all of these slides,
except for, I got about here and I ran
out of time. So I cut my little illustration.
One of the things that is scary about this,
though, is that some of the things that get
cut are the things that we, as developers, think
are important. Performance. Testing. Correctness. All these things can
get cut if you're not careful. So if you
value that, make sure that it's put high in
your priority. Make sure that you guard that against
the deadline.
OK. Another option. If you're not gonna get it
done and you can't ship later and you can't
cut features, well you can add more people, right?
Well, you could go read the Mythical Man Month,
but basically boils down to this. Unless you've got
a project where everybody can work completely independently, you're
gonna have to start talking to each other. Eh.
It's kind of uncomfortable.
So, I'm about to miss my deadline. They pull
you in to work with me. Now you and
I have to start talking. We've gotta make sure
that we aren't gonna be stepping on each other's
toes. We've got to keep each other appraised of
the situation. We've gotta understand which direction we're both
going in.
That adds overhead. And if you're splitting up work
between two people, it means that you're gonna start,
like, depending on the other person to get things
done. And if I'm waiting on you and I'm
twiddling my thumbs, that's sort of wasted time. That's
time that's not actually going towards getting the work
out.
So, adding more people sometimes works. But sometimes, it's
just gonna make everything go more slowly.
Oh, and if you do add more people, make
sure they get along. Cause nothing is more awkward
than running up against a deadline, working with somebody
who you want to punch. Like, this is how
sparks fly, right? You don't want to do this.
All right.
The final way that you can deal with a
deadline. If you can't two people to do the
work twice as fast, maybe you can make one
person work twice as hard. Ah. This really sucks.
And I'll tell you why.
It works. It can. Honestly. But it's not sustainable.
And I don't think any of us enjoy it.
Look, think about this. You've got eight hours to
work. You've got eight hours to sleep. And then
you've got eight hours for your daily commute, for
cleaning up after your dog, for cooking dinner, for
spending time with your friends, your family, for reading
seventeenth century poetry.
Where's that overtime gonna come out of? I gotta
hint for you. It's not coming out of work.
Bummer. OK, your only two remaining options are sleep
and what I would like to call life. So,
if that time's coming out of sleep, you're gonna
be tired. You're not gonna be very proficient. You're
not gonna be thinking straight.
We make the stupidest mistakes when we're up at
3 AM pounding on our keyboards. So quality takes
a hit. Shoot. Well, OK. What about life?
Use up a little bit of life to get
this out the door. This, this is the path
to burn out. To depression. Use it very sparingly.
Use it wisely. Think to yourself, is this more
important than cleaning up after my dog? Is this
more important than spending time with my kids? Depends
on how much you like your kids, right.
Just be careful. That's all I can say.
All right. Let's talk about one more of the
Dark Arts. Deadline hardening. This is the magical thing.
Whoops. I don't want to show this to you
yet. I gotta tell you about it first. Because,
here's what I love about this one. It happens
to us all the time, and every time it
does, we're like, totally surprised that it happened. We're
like where? Where did that come from? And I'm
like, what? Didn't this happen to you last week?
Or yesterday? All right.
Here's roughly how it goes.
Somebody comes up to you and they're like, hey,
let's try to release by the end of the
month. And you're like, um, I don't think we
can actually do that. But I'll try.
OK, and you go back to your keyboard really
quick, right. You know. Clock spins. Pages fly off
the calendar. Eighties work montage. All of a sudden,
manager comes back and they're like, hey, we need
to release by the end of the month. And
you're like, wait, what? Why? Why do we need
to release by the end of the month? And
they're like, we've got customers waiting on it now.
It's like, what? Why, why did you promise that
to them? And I'll tell you why. They heard
you say that you were going to try to
do it by the end of the month. Now,
I know that what you said, in your head,
was hey. Get out of here. I know that
what you said was, leave me alone, I gotta
code. I know that what you said was, I
don't see you.
But what they heard is, I'm on it.
It's a bit of wishful thinking on their part,
but it's true. Look, don't commit to making any
deadlines that you don't think that you can meet.
And saying that you'll try is committing.
Look, people are less likely to turn a goal,
a soft deadline, into a promise, a hard deadline,
if they think it's risky. When do they think
it's risky? They think it's risky when they know
that there's uncertainty. They know it's risky when they
know that the amount of work that you've got
to do is large. And that you're likely to
go over the deadline.
So, communicate your status and risk often.
Communicate uncertainty.
If you take nothing else away from this, communicate.
Make sure that other people understand what your view
of the world is right now. Because if you
don't, that's how you're gonna end up with unreasonable
estimates and. The other thing in my title. I
can't remember it. Awesome.
That's my talk. You guys have any questions? Wait.
Clap first.