Uh just a quick self intro. My name is Alicia and um I started off my career at Microsoft where I worked on remote desktop, working on things like display drivers and networking and then moved on to Dropbox where I was one of the earlier engineers there.Um I worked on all kinds of things from uh the diversity initiative to the intern program to my actual job which was a software engineer on the desktop client and eventually manager. Um At some point, I left Dropbox feeling like I wanted to try my hand at having some more social impact than just working at your Garden variety tech company. And so I left and landed at the Chan Zuckerberg initiative which is Mark and Priscilla's foundation. And I spent a couple of years there working on criminal justice reform, housing, affordability, economic opportunity, education, lots of interesting stuff. Um And then most recently I've been at Co Procure um which is a start up that is trying to help the government more efficiently procure goods and services as well as help small businesses, small and diverse businesses um sell into government and get access to that one point.

$5 trillion a year that local governments are spending. Um I think this is not gonna take up the whole 40 minutes. So uh if you have questions other than this talk at the end, I love talking about uh technology for social impact, hiring and managing software engineers, um cats and knitting diversity in the tech sector and low brow, low brow fantasy fiction. So just priming your Q and A so on to the actual talk at hand. Um When I was at Dropbox, there was a product manager training and um I heard rumors that at that training, the P MS were swapping notes about every engineer's multiplier. That is to say if John, the engineer tells you that it's gonna take a week to get this thing done, you pencil down two weeks and if Joe tells you it's gonna take a week, you better budget three weeks. Uh And to toot my own horn a little bit. Um This PM told me that I was the only engineer at the time who was, who was volunteered as having a multiplier of one. And could I please give a tech talk about estimating software tasks? So five years later here, you all are sitting at the very first session of this talk. So if you are a software engineer or um have worked with software engineers, you've probably heard the question. So when can we ship this thing?

And uh almost everyone is really bad at answering this question, uh famously bad at answering this question. Now, you know, sometimes you think, well, you know, we're super agile or they'll ship when we ship, like, why does it matter? But oftentimes there's a need for a real hard ship date. Um Sometimes you have an externally announced date uh comes with a press event or you're coordinating multiple teams shipping one large uh project. And so you need to have a single date that everyone agrees on. And uh what happens when you're wrong? Uh Typically it's that someone is overoptimistic and says they can ship sooner than they can. Sometimes it goes the other way uh where your estimate is too far out, but that usually just results in scope creep. That's a topic for another day. Um But if you're over optimistic on how long it's gonna take, uh what happens on launch day is that your manager was really annoyed at you because you made her look pretty bad. Uh The sales team is pretty annoyed at you because they are breaking all of their promises to their clients and your team is pretty mad because they've been working nights and weekends for a few months straight trying to meet this impossible deadline. And all of your users are really mad at you because you delivered your product late or you delivered a really crappy product probably you did both.

So the next question is why is estimating so hard and to get at this question, we're going to do a little exercise that I have shamelessly stolen from an intro to development class that I took at Microsoft. Of how long does it take to paint a room? Uh The nice thing about this is that it has nothing to do with any specific software system. So you don't need a lot of context to do this. But I hope that you all can, uh, can join me in this exercise because it's a bit of audience participation. So if you can, um please get out a notepad, digital notepad is fine and take a little bit of time to think about your estimate for how long it would take to paint a room.

So I just, you know, do do, do, do

not gonna sing the whole time. Yes, I see. Some people are getting at the problem here. Yeah. So if you're done with your estimate, if you already have an answer that you're confident in, then you're a novice estimator because we haven't even talked about the spec yet. So, uh let's say that the room is 12 ft by 10 ft by 10 ft. So that's like an average bedroom and we're painting it off white. So are we off to the races? Yeah, 21 year old me was like, yeah, I got everything. Let's go. No, we don't have everything. Uh you must buy all of the materials. So don't assume that you have everything that you need. Uh, the room is fully furnished and currently being lived in, it has one door, three windows and the current color of the room is Kermit Green. So now we're gonna do this thing. Take a minute and we'll time one minute and, uh, really hold yourself to writing it down. So let's talk a little bit about how far we got. So, let's suppose it looks like this. Buy the stuff, prep the room, paint the room clean up, right? So two hours to get to the store and back prep, painting clean up. Yeah. So 6.5 hours. Is that right? Nope, we need a prototype before we can realistically do this. Especially if you're announcing a date that others are depending on. You need a much higher level of confidence than just putting something out there. So first you research I'm gonna Google, how do you paint a room and learn about all the different types of paint?

Like what is primer? Uh are you using rollers? Are you using brushes? Do you know what you call the things that you lay down on the ground so that the paint doesn't drip on your carpet and then confirm the requirements off white is not an actual paint color. There are many, many different types of paints and brands and so you i if you're not the final decision maker, then you gotta go decide like get everybody on the same page also are you painting all of the walls or just an accent wall? What color are you painting the trim if anything? And do you know what eggshell and satin refer to? Uh those are different paint glasses. There's at least six different paint glasses. So you had better also confirm that you didn't even know paint glasses existed like before you googled it. Now, the next step, we're gonna kind of skip over because it's not that relevant to software engineering. But obviously, you would have to go buy the stuff. Hopefully, you made a good shopping list. Otherwise you're going back and forth to the store a few times. That's also maybe part of your estimate. Um, and then prototype. So actually prepare a small area of your wall, um, apply the paint, let it dry and then if you're not satisfied, apply some primer. Hopefully you managed to buy a sample of that, let it dry, apply some paint over that.

And so after you've done your prototype, you've probably learned, oh, we got a prime and then paint and in fact, paint a couple of coats because your wall is Kermit green and you lay on one layer of white paint over that you're gonna have just slightly less Kermit green walls, even four coats probably still gonna be kind of green.

And then the other thing you learned is that prepping to paint takes a really long time. Uh, if you've ever thought about what it takes to turn a room from this to this. There's a lot of shuffling furniture around, probably needing two people to get the bigger items out, uh, taping and taping. I mean, I don't know if you realize that like taking down the paintings off of the wall would leave holes that you're gonna have to patch and that you have to like unscrew all the light switch and outlet covers. So your first estimate probably didn't account for that if you've never painted before or if you didn't do a prototype. So let's go to back to software for a second. Uh Research improves your design. Don't re invent the wheel if you have a problem that needs to be solved. Are there off the shelf solutions that already exist either inside your company or in the community that you can just use? How is everyone else doing it? Secondly, prototype improves your estimate and a cheap prototype can save you a lot of time. There's a number of times that I've done a project and the sequence of events went like this first, I'm like, oh yeah, we're gonna build it and we're gonna build it like this.

And then I do a little research and I'm like, oh somebody else already built it excellent. Then I prototype integrating that library and it's like, oh somebody else built it not quite right for our purposes. So we're gonna have to modify it or build it ourselves after all And uh if your prototype was super cheap, didn't integrate with any real production systems, then you saved yourself a lot of time chasing down all of those dead ends. Uh And so it will get you to your final product faster. And of course estimates improve with experience if you start up a website before you know how long it takes to stand up a website. So, you know, OK. So back to the real estimate now that we've done the prototype and the research, we have an idea of how long this is actually gonna take. Uh We're prepping the room, which means clearing all the walls, getting the furniture away from the walls, washing the walls, filling in any of the holes and sanding them, taping down all of the edges and trim and floors and stuff and securing drop cloth. Then we got to prime the room. So mix the primer, apply the primer, wash all the rollers and brushes so you can then apply the paint, pour and mix the paint, apply one coat and let it dry, apply second coat based on your prototype.

You know how many coats you needed and then you gotta wash the rollers and brushes. Yes, I can see some of you have repainted before. Once you've done this multiple times, uh you get really good at it, but it's very rare that you get to do a software project multiple times. It's rare that you ever have to do something exactly the same twice because that's the whole point of software. So that adds up to 14 hours and 30 minutes, which is a lot longer than our initial estimate of 6.5 hours. In fact, looking back on this estimate, which is the estimate that I gave the first time I did this exercise at Microsoft. It's actually pretty embarrassing. You feel like your past itself was a little bit BBB. Um And so this also means that the research, the requirements like going back and forth on the scope and doing at least enough of the prototype that you're confident on what the design of the project is gonna look like. These are pre estimate steps. So don't even give a date until you've done these steps because you're gonna look pretty dumb. If your manager asks you the first time, you're like six weeks and then you turn right around and you go, never mind. Just kidding. 14 weeks.

It's a great way to lose credibility. And yeah, doing this work takes time. The research takes time, the prototype takes time. So if someone shows up at your desk and asks you, when can we ship this? You tell them, I don't know, but I'll be able to tell you in a few days and you have to budget those few days into your work plan also. All right. So 14.5 hours, is that our final answer? Can we get painting. No, still can't get painting because the, the question we answered was how long will it take strictly the time required to do the thing? But the answer we're actually looking for is when can we ship? And the difference between those two is that the time elapsed includes things like meetings, vacation, other projects, dealing with site outages, checking Instagram, everything that happens during the course of a day. And so how do you actually account for all of those things?

Some of which are pretty unpredictable. Uh There's lots of ways of dealing with this funny. We come back to applying a multiplier. Um Every different has uh every person has a different multiplier. So you can always try to take that into account beforehand before you give it to the PM. Um You can also add buffer time for unexpected things like, you know, forgetting to buy a ladder, having to go back to the store and come. Uh You can also measure and improve and continually get better. So start by measuring uh start by estimating small to medium size tasks and projects and then measuring the actual time that elapses from the beginning to the end of doing that task and then reflect on how good your estimate was and work your way up to gradually larger tasks.

Um There's actually a really amazing and hilarious article by Joel Spolsky on this called evidence-based scheduling that gets into extreme detail on how to do this so I won't cover it. Um, it, if you read the article, it does seem like a lot of work. It is kind of a fair amount of work but like any skill that's worth developing, um, it's worth putting some time into. Now, all of this is assuming that somebody even bothered to ask you for the estimates that doesn't always happen. So, what if the estimates aren't yours? What if your tech lead just kinda offhandedly throughout? Oh yeah, it's gonna be about three weeks or um or your CEO tweeted to the entire world that it's gonna be available by the end of the year. And yes, uh Jennifer makes an excellent point, which is your buffer should be relative to the overall size of the project and the relative complexity and risk. Um Anyway, uh if you're on the hook for delivering this project, even though somebody else has provided the timeline for it, what can you do? Well, especially if the stakes are really high that delivering on time is really important. Then first you gotta do the work of estimating as we just described, it's actually kind of a lot of work.

And then once you have the actual more correct estimates including buffering, including multiplier, all of that stuff, then if the, if your estimate is really different from the timeline that was provided, you need to speak up and this can be really hard, especially when inside the company, everyone's like Hey, Project Unicorn and Operation Rainbow are gonna launch by Christmas.

Everything is gonna be wonderful. What do you mean we can't do it in time? Your negative attitude is what is holding you back from being successful in this company? That's just not true. What you're actually doing is trying to prevent your team or company from promising this and then in the end shipping this. So remember what's on the line? Is everybody in the entire world being angry at you. So don't let yourself be intimidated into science. Don't revisit your estimates and revise them downwards because of pressure. You know, you, it's easy to fool yourself into thinking, well, you know, it's just pain a little bit faster. It doesn't work like that. Uh It takes a lot of work to get really good at estimating, it takes a fair amount of work to even just create one estimate. And it takes a lot of courage to stand up and say you're wrong. We're not gonna be able to ship that set of features on that timeline, but it is really important to do that because if you do it right, then everybody can be happy instead. Um Yeah. Uh And again, Jen makes some excellent points um creating a good schedule um and a very aggressive schedule with good estimates will force people to have real discussions about what's important and what's not important. This is addressed pretty well in Joel's article about um about evidence-based scheduling.

But prioritization is a whole another set of topics that I could also chat about for a long time. Uh But anyway, so that concludes this presentation.