Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking a little bit about estimating. We are awful at estimating. That's not just me sharing my opinion. This is something that has been proven over and over. You've probably experienced it. You've probably seen it, especially if you work in an environment where estimation is a constant process. Estimation is so hard to do. Why is estimation hard to do? Oh, for a lot of fundamental reasons that have to do with our humanity. We aren't very good at estimation. And part of the reason we aren't good at estimations is because we never really found a need for estimation. We haven't lived long enough to see estimation become kind of a part of our necessary skill set in order to survive. Of course, it's a necessary skill set in order to scope most of the projects based on the business model of most agencies in today's world. We have to talk about estimation in a way that informs us and gives us a way of doing whatever it is the estimation is intended to do. How do we do something that we're fundamentally flawed at doing? First we have to understand our fundamental flaws. The first flaw is that we know what we are capable of. Quite often this is not the case. And very often it is in one direction or the other direction. We might be more capable of what we think we are on one day and we may be far overconfident on another day. Another problem is that we estimate based on average output rather than based on a daily output. Because if you were to look at my output or at your own output on a daily basis, you would find that output is not static. We do not have an absolute determining factor that explains what our average output is going to be. It is very much varied and it can vary from week to week or from day to day or from season to season or even year to year. Of course it helps if we are constantly ensuring that we have a regular process, that we have a routine that we follow as often as possible, that we unify our efforts as much as possible so that this estimation process becomes a little bit easier. We know what our basic output abilities are on an average day. Now that is simple to say but it is also quite difficult to implement in practice actually having a routine that allows you to estimate is one of the fundamental steps that is necessary in order to estimate properly and it is a fundamental flaw. We do not understand what we are capable of because we have not created a routine that allows us to measure what we are capable of. Perhaps just as important though is that even if we did know what we were capable of on an average basis, if we had a nailed down routine and we protected our hours, we knew exactly what we were planning on doing and we had figured out over time what our average output was, we can't predict the future very well either. We can't predict the unpredictable things that may happen to us. This includes things in your personal life as well as in the professional world around you. For example, if you are a web developer, imagine how little you would get done if for every project you had to rewrite a web server. Of course this is an exaggerated example but imagine a new tool that comes out that enables you to do something on every project that previously you had to do manually. Of course it is not always a positive thing. It is possible that in the future more and more browsers will cause you to have to do more and more cross browser work. These relatively unpredictable events cause a major difficulty when we are estimating. Finally, the primary means of estimation that most people use, which is time, is very difficult for humans to see in a volumetric manner. In other words, it's difficult for us to look at a task and assign to it a certain amount of time. As it turns out, humans are pretty good at estimating things that are half a day or less worth of energy. But anything more than that, it becomes kind of cloudy. It's difficult to determine how long it's going to take to build especially large features on a given software project. So estimating those large features is a very difficult process by nature. And especially so if you are estimating with a measure of time. Of course we can't defeat all of these problems, but there are some ways to get around these problems. I'm going to take a quick sponsor break and then we'll come back and talk about a few of those ways to get around these problems with estimation. Today's episode of Developer Tea is sponsored by DigitalOcean. DigitalOcean is simple cloud hosting built for developers. They're dedicated to offering the most intuitive and easy way to spin up a cloud server. And in just 55 seconds, you can deploy a solid state drive cloud server. Plan start at only $5 per month for 512 megabytes of RAM, a 20 gigabyte solid state drive, one CPU, and a full terabyte of transfer. In addition to offering simple and affordable SSD cloud hosting, DigitalOcean is dedicated to building out a strong community and supports open source software. They offer a vast collection of hosting tutorials and invite Developer To submit articles and they pay $50 per published piece. Deploy your SSD cloud server with DigitalOcean a day by going to digitalocean.com. Now DigitalOcean has been kind enough to provide Developer Tealisteners a discount of $10 when you use the code Developer Tea. So go to digitalocean.com and use the code Developer Teato get $10 off today and you'll get up and running with your own SSD cloud server in just 55 seconds. That's digitalocean.com. I've been talking about the natural difficulties that we have with estimation. Specifically, it's difficult to know what we're capable of, especially if we haven't nailed down a routine. But even if we do know what we're capable of, it's difficult to predict the future. It's especially difficult to predict external things that might happen to us that we don't really have any control over that we can't really affect in any particular way. Finally, I mentioned that it's very difficult for us to estimate the amount of time that it takes to do a particular task because it is fundamentally difficult for humans to perceive time in a volumetric way. In other words, to see time in such a way that it can be assigned to a particular task. So how do we get around these problems when we are scoping a project, when we are trying to estimate to scope a given project? As I mentioned before, we can't get around all of the problems. So one way to reduce the effects of these problems is to reduce the need for estimation as much as possible. One way of handling this is to provide different tiers of project types. For example, if you are an agency, you may have one very small project type, one medium project type, and a large project type. What this allows you to do is price all of your projects at one of those three tiers. Each of these tiers comes with their specific feature sets and the scope is already decided before you even start on the project. Of course, this isn't always realistic for every client, but this could work for many clients. This also alleviates the necessity to estimate based on the amount of time a given thing will take. Instead, you can take a project and a project's requirements and place it on your scale between small to large. As it turns out, humans are quite good at relative estimation. In other words, if you look at two cups, you can see which one is larger than the other cup, even though you don't know exactly how much larger. In fact, if you were to look at one cup, you couldn't say how many drops of water fit inside of that cup very easily. But you can relatively accurately look at a cup that is two times larger than another one and see that it is about two times larger than the other cup. So what do cups have to do with software development? Well, if you have a single size cup that you know what the size of it is, then measure everything else by that cup. Some people call this an anchor. The idea is that you are very familiar with this particular estimated piece that you've done it over and over. You know how much energy it takes. You know about how much time it takes to finish that particular piece. An often used example is a user authentication stack. If you think something will take about two times as long as a user authentication stack would take, then that gives you a relatively better estimation than if you were to try to estimate the thing on its own. My final tip for you today is to measure, evaluate, adjust, and repeat. This idea comes from the Agile methodology that you should iterate on the process of estimation. In every cycle, say every two weeks or so, you are given the opportunity to look at a set of tasks and estimate the amount of intentional energy it will take to accomplish those tasks. Two weeks later, you'll be able to look at what you actually did versus what you estimated you could do. If you consistently see that you're 5 or 10 or 15% over estimating or underestimating, then perhaps you adjust and re-estimate taking into account your natural tendency to over or under estimate. Eventually, over time, the data will inform your future estimations and make it more of a process than a guessing game. At the end of the day, though, estimation still is a hard problem to solve. So when possible, reduce the amount of estimation that is necessary in order for you to conduct business. Understand that humans are fundamentally flawed when it comes to estimation and focus on relative estimation over absolute estimation. Give yourself an anchor. Look at tasks with relation to previous tasks that you've accomplished and measure them with that relation in mind. I hope that you've enjoyed this episode of Developer Tea and I hope that estimation becomes a little bit easier for you every day. Thank you so much for listening and I hope you will listen again. If you have not voted for Developer Tea and the 16th Annual Net Awards, I'd appreciate your vote very much. This will mean a lot to the show's future and it is all because you all are listening and because you have nominated the show on the Net Awards. So if you would like to vote, go to bitley. That's bitley.ly slash vote t. All of that is lowercase. So bitley bitley bitley slash vote t. Thank you so much for listening and until next time, enjoy your tea.