The Rogues talk estimation.

 

Pants not found. Abort, retry, or ignore? [Laughter]

Oh, man!

I'm selecting ignore.

Usually, when I run that, I get the warning, “Pants not…” And people are like, "Abort! Abort!"

What do we do without James?

Have I told the joke about talking wheelchairs?

Hey everybody and welcome back to Episode 35 of the Ruby Rogues podcast. On our panel today, we have Avdi Grimm.

Hello and I estimate that I need more coffee.

We also have David Brady.

Hello…and holy crap! I estimate that there is exactly one Labrador Retriever in the pond in front of my house. Holy freaking crap! I have triple data to back this up.

[Laughs] Oh dear! We also have Josh Susser.

Hey, I estimate this episode will be complete in seven and a half minutes.

And I'm Charles Max Wood from Teach Me to Code and I estimate that I will be off of the antibiotics in about a week.

Woohoo! How soon do you estimate needing them again? Because it's all about lifestyle, my friend.

I don't even want to think about it. Alright, let's get into this. We are going to talk about estimating today and I think this was actually a topic that was suggested by James. So, I guess he needs help estimating just like the rest of us.

Did he want to do it?Or did he just want to inflict it on us? [Laughter]

I want to know if we're stealing the chocolate pie from the window sill or if we're stealing the turd from his bathroom? Is he going to hear this episode and go, "Ahhh," Or go, "Ha, ha!" [Laughter]

We'll ask him when he’s back. He'll be back next week.

No! We should estimate it! [Laughter]

We should predict!

If we estimate somewhere between is that like poop versus pie content?

Poop versus pie? No, poop versus pie, actually poop over pie is how many times a dog willpoop in a circle. [Laughter]

Or in a half circle, I guess. Otherwise, a full circle would be poop over two pie.

Or Tau.

There we go!

Or Tau, yes!

Who is it that keeps pushing Tau, was it Michael Hartl?

Yes,everyone should read his Tau Manifesto.

Alright. So anyway, yeah, his description says, “For me, the hardest part of programming is still estimation.” We talked about some ways to make better estimates, some ways to avoid making an estimate and what to do when you have no choice. I think this is kind of interesting just because when we're talking about estimation, in a lot of cases, we've gone beyond the scope of just programming. This really comes down to your ability to solve the problem in the amount of time you thought it would take you. So, it's a person problem, not an actual programming problem per se.

And a person problem can be extrapolated if you work at a company that pays you a W2 wage. You are basically betting the company's money and time and schedule that you can finish what you say you can. If you run a small consultancy and the client has asked you for a fixed bid and you were stupid enough to agree, like me on a client that I won't name, you're now betting your lunch, and your rent money,and your ability to continue operating as a business on whether or not you can deliver the software. And fortunately, so far, we can.

I feel like we're missing something. Josh,what is the definition of estimation?

Hang on I may be able to come up with one for you in just two minutes. [Laughter]

If you can't define it, can you just loosely predict?

Is it a hard number?

Yes.

Just loosely predict what it means. [Laughter]

So, estimating the effort of creating a piece of software is what you do when your boss comes and hovers over your desk and says, "How soon will you have this done?"

Two weeks!

So, that’s always interesting is in a lot cases people want to time estimate. I've seen other of estimates where you're basically assigning it like a complexity number as opposed to a time number.

Sure.

But yeah, you get the upper ups who translate hours to dollars. And so, they want to know ho many hours come in so they can budget how many dollars they're going to spend on it.

Well, to get a little serious, there are several forms of estimation that people talk about frequently. A lot of people, when they do project planning, they bust out Microsoft Project and roll out the Gantt Charts and the PERT Charts and all these. And I think those are less useful for predicting how long it's going to take to complete your project and much more useful at predicting how efficiently you can utilize available resources.

Yeah.

So, they're not the same thing then?

Actually, I was going to ask the same thing.

Yes. Project planning and estimation are different things.

Okay, yeah. I was going to say project management, project planning/project management. The Microsoft Project, the real great thing about that is that you can kind of see how fast your burn down is failing to burn down. And you can, in theory or in practice, this never happens or I have yet to see it happen. But in theory, project is the thing that tells you, "Okay, we're going to need 30 licenses of TextMate in the next 45 days." So, your Project Manager can order that and have that on everybody's desks the day before they need it so that nobody is sitting around waiting for their licenses or for whatever other arbitrary resource.

I guess the thing that does actually happen is that you can see, "Okay, at this point in the project, we need to start getting servers allocated.” And we need to not do that for the firstsix months of the project beyond the staging server, and the test server integration. We don't need to start rolling out production clusters until this point in the project. That can save you money so that you don’t -- it’s the don’t start fully ramped up on day one because you're not going to be able to leverage your entire infrastructure.

Alright. So, let's get back to estimating then. So, what tools or estimation methods have you guys used?

You didn't expect me to go off on that tangent, did you?I screwed up your estimate. [Laughter]

So, just basically, estimation is when you have a programming task and you look at the description of the programming task and then you make a stupid wild ass guess about how long it’s going to take to complete it with the resources that you have on hand.

Okay.

Which brings to mind a quote by George Burns which says, "Sincerity is everything. If you can fake that, then you've got it made." [Laughter]

I like it.

Estimation is kind of like that. Nobody can really predict the future. The only way to really predict the future is by doing it and then sending a message back in time telling yourself what you did.

I've been working on that for weeks.

So, what are the things that throw off estimations?

Real life?

There is the thing that I call the ‘ugh!known’ which is spelled U-G-H-!-K-N-O-W-N. It's just like the, alternately, I'll call them the ‘Oh craaaaap’ moments where you kind of go, "Ahhhh, yeah. We forgot about this." Or the ‘oh yeah, we need’ moments. Basically, oversight is the biggest killer to estimations or a failure to predict dependencies. You'll sit down -- this happens in every project poker I've ever seen. You'll sit down and somebody will say, "How long will it take you to write the API to save a customer?” And you'll say, “That's a freakin’ eight. I can't estimate that.” And they'll like, "C'mon dude! It's 19 lines of JSON. How long is it going to take you to write that?” Okay, fine. It’s a two-point story.

Then you sit down and you find out that customers can't be saved unless they have valid credit card information and you can't access valid credit card information without actually through the Chargify gateway. And all of a sudden, you have this huge dependency on Chargify because that piece isn’t written yet. And it didn't make it into -- because it wasn’t a visible feature, it didn't even make it in to planning poker so you didn’t estimate it at all. And you basically got negotiated down from your initial estimate which was correct which was an eight, which is ‘this is too big to estimate’. And basically, somebody came along and negotiated with you, usually somebody at the CXO level because they don't want the project to take as long as it's taking. And so, they basically say, “Let's not estimate for this huge hidden dependency.” And that's a recipe for having your velocity drop to zero.

Planning poker, a lot of people don’t get this but planning poker really is not a negotiation process. And actually before we go on, we should probably say what planning poker is.

And velocity, I think.

And that, whatever that is.

That’s fair.

And points.

Points.

Points don't matter. Since I brought them up do you want me to just quickly explain them?

No.

Okay. [Laughter]

Anyway, this is going to be really interesting to listen to later on. [Laughter]

You're usurping the definer.

This is true. Take it away, Josh.

No, no, no. I just wanted to be able to get the definition in, in less than three or four minutes. [Laughter]

And then you've got it right although we are burning that three or four minutes right now.

We'll still come in ahead of schedule on this one though.

Yeah.

So, points are a measure that you use to estimate the effort for completing an Agile Development story. Points are intentionally not unit-ed. A point does not mean one day or one hour or some fraction thereof. A point is, depending on the team, it can be mapped to complexity,it can be mapped to, "Oh, this is likethis other story that we did before and we know it was about this much effort.”

I like defining points as measures of complexity and single point stories tend to be things that are simple and straightforward for the product owner to accept. And so, they hover somewhere between how much effort it is for the implementer to create but there's also some crossover into how complicated the feature is from the user’s perspective. Just because if it's really simple to code it up but it's really complicated to describe in users from users’ group, probably there's a lot of testing that you have to wrap around it no matter how simple the implementation is.

Yeah. I remember when we were working at Public Engines,we went to the Agile Roots Conference which is a small local conference on Agile. We talked our boss into going too and when he came back, he had this whole estimation scheme and basically, he had all of the points mapped to a certain number of hours. We were estimating based on 32 points in a week or something like that and all the different points were like a different power of two or something. It was really interesting. I don't think we ever actually got 32-hour point, point hours, whatever, in a week. I don't think we ever hit that velocity just because....

That's a good opportunity to define velocity which is a term I hear a lot of people have bad associations with these days.

Yeah.

Josh...

I'll let Avdi continue.

No, no, no. I was just prompting you, Josh.

Oh, okay.

Everyone kind of implements that ‘define’ is ‘delegate to Josh’.

Exactly. He is the definer.

And ‘defined?’, is that ‘Josh has spoken, true or false’?

Yes.

I have a funny story. ‘Defined?’ failed on me the other day. But anyway, go on.

[Chuckles] Did you do ‘defined raise error new’ or something? [Laughter]

I saw a tweet about that the other day. Okay. So, velocity is if you're doing your Agile development, you do a couple of iterations, then you can look and see how many points you got done in each of those iterations. So, if you're using Pivotal Tracker, it keeps track of this for you. So, it keeps track of how many points you've completed in the last three iterations and then gives you the moving average of those. It's kind of a guesstimate but it’s based on an algorithm to tell you how much work you’re going to be able get done in the next few iterations. So, you go through, you do point estimates on all your stories. You do some work for a couple of weeks and then Tracker figures out, “Oh, if you operate this effectively for the rest of the project, here's how long it will take you to get done.”

Funny story on that one, I have all my clients using Pivotal Tracker. So, I got in and I had done a ton of work for one of my clients and it doesn't count as done until it's approved. And so, the first week I had like zero points and the second week I had like three points so my velocity was at one. That week, I had all this stuff built up because the client has his son managing the project and the son had been prepping for and then completed his finals. So that next week, he approved 42 points. And so, my velocity literally went from one or two to like, 18. So, it is an interesting way of measuring speed or efficiency,or whatever you want to call it, velocity. But you know, you have to realize that not everything -- it's not a clear cut way of measuring exactly when you’re going to get done either.

The really interesting thing that's been my experience and this is a little bit counter intuitive but if you are a project manager, you really need to take this to heart, and that is the fact that if you push velocity, it will go down. If you try to push it up, it will go down. If you go to the team and you say, "Our team velocity right now is 18 and I'm looking at, when we’ve told sales that we're going to hit our ship date. Oops, that's an Agile mistake right there. I basically have committed this Agile sin and now, I want you to cover this blank check that I wrote so I need your velocity to go up.”

This will cause velocity to go down because what will happen is, you'll go in and you'll say, "Okay. I'll bid two more points than I can actually do.” Or you will start negotiating in planning poker. Again planning poker is a hostage situation, we do not negotiate. And planning poker becomes a negotiation which causes your estimationsto be wrong which will ultimately cause your velocity to go down. So, if your velocity is too low, I don't know what to tell you, velocity is what it is. I'm trying to manipulate it. I worked at a shop full of really, really bright people and the CTO liked to manipulate velocity. And he hated the fact that our velocity kept dropping. One team at the company that was directly managed by the CTO, I actually flipped over from -- our velocity was at like 12 and that was basically each person was apparently only doing 12 hours of work a week even though points aren’t unit-ed. And I was a little frustrated about our velocity. And then I flipped over to his team and their velocity was zero. After six months of development, their velocity was zero. And we had kind of an emergency meeting that our velocity was just too freaking low and he wanted to change the pointing system to basically make the points much, much cheaper so that we could collect more of them. I kind of looked at him and…

So, the points really didn't matter.[Chuckles]

So, the points didn't really matter.Yeah.

I know what my pick is today. [Laughter]

Yeah, whose line is it anyway? [Laughter]

I kind of looked at him and I said, "I think you might be ignoring the message that this zero is trying to tell you. And if you change that metric, it isn't going to change velocity. The team is going to settle out at a newly, whatever you change this metric to. The team is going to settle out of that new point because there's something wrong.” If your velocity is zero, there's something wrong. In their case, it was institutional ADD. Every two weeks, they change their mind. Well, every three days, they changed their mind of where they wanted to go.

There’s only one knob that project owners have total control over, they can turn and change things immediately and that is features. You can cut features and I think that’s the thing that the teams are too often afraid to do. But it’s the only thing that you really have control over. You can say, “We’re not going to implement this.” Or, “We’re going to implement this,” in a way that’s smaller than originally envisioned.

Well, one other thing that I want to point out here too is that there can be some back and forth over estimates but really what it is, is here’s our feedback on this feature. So, you can actually give them feedback that will cause them to cut or add a feature. And since you’re so close to the project, so close to the code, you’re in a position to give them that information and say, “This is going to take too long,” or, “There’s a tradeoff if we implement this,” as opposed to implementing maybe something similar in a different way that can save you time or complexity, or whatever you’re trying to measure.

So, there’s a couple components to making an estimate, I think. One is the amount of time or effort that you think it’s going to take. And then, I think some people call it a confidence factor that goes with that estimate of effort. So, someone might come to you and say, “Okay, I need to add payment processing to this application.” And you say, “Okay, that will take two weeks and my confidence factor I’m at is about 50%.”

Right.

For all you know, it could be plus or minus 50% on that estimate, or however you choose to express that.

And I learned a couple of years ago when I was working with a client, that the client hadn’t managed a web development project before and I didn’t realize how green he was. And he asked me about doing some feature and I said, “Well, I think it will take about a month but none of us on the team have used these technologies that you’ve dictated to us. So, we don’t really know enough about them to make an estimate with any amount of confidence at all. So, consider the risk on this unbounded.”

And he didn’t understand, when people say ‘risk’ on a software project, they don’t mean the risk that it’s going to fail. They mean that it’s the risk that it’s going to take longer than expected. Because with an infinite number of monkeys and Vim editors, you can write anything, small matter programming. There’s very few things that you can’t actually do if you have enough resources. So, the risk isn’t the risk of not being able to do it. It’s the risk of not meeting the schedule estimate.

Right. Well, that leads me into another thing because I’ve had several clients ask me for estimates on how long it’s going to take me to build in whatever it is that they want. And so, they’ll send me a list of features and then basically, I usually wind up sending them back a list of questions. But once I have enough information to where I feel like I can estimate, usually what I wind up doing is I’ll get out the spreadsheet and I’ll estimate in points. What I’ll do is I’ll give it a best case and a worst case. So, I’ll basically say, “Look, under ideal circumstances, it will go this smoothly. If I completely understand the problem as you’ve given it to me right now, this is how long it’s going to take. But here are the unknowns, here are the risks like you’re talking about. And so, here’s my worst case estimate.” And it’s usually a lot worse than the best case estimate.

Then what I can do is I can take those points and I can sort of extrapolate hours. So, I’ll start guessing, “This is a one, so it’s a couple of hours.” You know, “This one’s a five, so you’re probably looking at a week or so.” And so, I can kind of break that out and then I can kind of say, “Okay. Well, then given the amount of time that I can put in on this and all of the stuff,” then I can break it down to hours, I can multiply in my hourly rate and I can say, “Look, this is about what I think it’s going to cost in the best case and in the worst case. And given that some things are going to go way better than expected and some things are going to go way worse than expected, I’m probably going to wind up somewhere in the middle.” And then, I hand that off to them.

And in a lot of cases, people look at it and they say, “Okay, your best case is like 10 grand and your worst case is 30 grand. So, what you’re telling me is you’ll come in somewhere around 20, maybe 25 grand?” And that kind of gives them an idea.

No, 40 grand.

[Chuckles] Right, exactly. But then, they kind of get that. I’ve had a few potential clients actually freak out when they saw the worst case. But I just have to tell them, I'm like, “Look, there are some things that I don’t know in here, and there are some things that we’re going to be figuring out as we go. And so, that’s just the way it works.”

But it is interesting because giving them a pinpoint estimate of how long anything’s going to take, I just don’t think anybody’s very good at that. The best thing you can do is you can say, “Look, if there’s this amount of risk, then I have to take it this way,” like you’re saying, your confidence in your estimate and being able to say, “It’ll be around this range.”

So, there’s an interesting question when you’re -- a lot of teams want to measure how well they do estimations. So, they’ll sit down and they’ll estimate things. And then, they’ll look back after the fact and say, “Well, we said this would take us a day and it took us a day and a half.” And they do that kind of analysis either piece by piece or an aggregate over the whole project to kind of see how they’re doing at estimation and how they want to get better. And let me see if I can remember where I was going with that.

The way you put that, you make it sound like they’re trying to outsmart themselves.

Well, I think that -- give me a minute and then I’ll come back to you. I distracted myself thinking about how to phrase that. Anyway, come back to me later.

If it helps, I’ll give you a breather. One thing that boggles my mind is that people will go talk to a house builder, a general contractor and they will say, “How long is it going to take to build my house?” and the contractor will come back and say, “Ninety days from dig to move.” And then, they’ll go talk to a Software Engineer, and the Software Engineer says, “I don’t know, I have no freaking idea.” And a house is way more complicated than software. I mean, you can touch it, you can feel it, you can look at it, you can see it.

There’s nothing in software that you can touch, therefore there’s nothing there; therefore, it costs nothing. How come this guy can tell me from the moment that backhoe breaks ground to dig the foundation, that 90 days later, I can move in and the answer is actually pretty simple. The answer is that contractor is building for a building company, he’s building for some home building firm and he only has five blue prints. You get one of those five. If anybody has bought pre-built, I don’t know what you call it.

It’s pre-fab.

It’s not really pre-fab, it’s…

But if you buy it as part of a development, where they give you the floor plans and say pick one...

Right. Chuck, you were in -- I’m in the McLean model of home out here and I can’t remember which model you were in. But I mean, there’s the McLean and the Victoria and there are only five models of home in my entire subdivision. So, it doesn’t quite look like cookie-cutter houses because the houses don’t all look the same. But it’s a little bit eerie because I’ll go over and visit the neighbor and I’ll walk in their house and it’s a completely different house and that’s great. And then, I’ll go right next door to the next door neighbor’s house and I’m in my house only it’s mirrored, it’s flipped.

It’s my house with the wrong carpet and the wrong color paint on the walls, and mirrored, but it’s creepy because I know that I can walk in, make a left turn instead of a right turn into the kitchen, and then make another left turn instead of a right turn towards the garage, and make a left turn instead of a right turn through the doorway into what should have been a closet but what happens to be the bathroom! And I know that the bathroom is there because they have the same exact model house as me. And that is why the contractor can build a house in 90 days because he knows that he can. He’s got a checklist. He knows that on day five, he needs to have a team out setting up the forms to pour the concrete. He knows that on day seven, the concrete truck needs to be there. He can pre-order the timber, the trusses to put in the roof for day 37.

So David, I think what that all comes down to is that people have been building houses for millennia and we’ve gotten pretty good at it, and we know how it works. But we’ve only been building software for what? Decades.

We’ve exhausted the -- I won’t say we’ve exhausted the problem space. But certainly there’s a phrase for this development that I’m in and it’s called cookie-cutter houses, and let me ask you a question about cookie-cutter software. People don’t come to you and say, “I’ve got this brilliant idea. I want you to build something for me in Ruby on Rails. I need the ability to write messages to the world and put them on a website, probably need a title and a body. And I might want to put hyperlinks and have text in there. And then, I want to have some kind of chronological listing of these posts. How long is that going to take?” Well, that’s going to take 15 minutes because there’s a video out there on how to build a blog in 15 minutes. It’s a cookie-cutter. Boom! You’re done.

But nobody wants cookie-cutter software. Everybody in software wants to solve a problem that hasn’t been solved before. That’s why I’m in software and not building houses. If software was cookie-cutter, and there is cookie-cutter software out there. There are companies that are just building the same thing, Version 3, Version 4, Version 5, and it really is the software version of digging ditches. It is absolutely, for me anyway, uninteresting, boring, make me want to crawl out of my skin. Alternately however, that software’s actually pretty easy to estimate because you’ve done it five times. You know kind of how long it’s going to take you to write the device driver for the next version of your application.

Right. They’re essentially just building the other house with the wrong carpet and the wrong paint.

Right. And there is a summary of waterfall development, which in a very quick definition, is where you plan, and then you architect, and then you design, and then you develop, and then you debug, and then you ship. And you don’t begin one phase until you finish the other and you never circle back. You do all the planning, then you do all the architecting, then you do all the designing. They actually came back and they said, “Turns out that does actually work if you have built the product three times before, because you know all the gotchas.”

Can I apply that to my life? I’d like to get all of the sickness out of the way, and then I’ll do sleeping.

And then, I wouldn’t work anymore, and then I wouldn’t…you know.

I’ve got good news for you, Chuck. According to the science, the waterfall method will work for your entire life once you have lived three times.

Okay. [Laughter]

Well, the thing about waterfall is that it’s all lies because nobody ever actually did that. Because if you’ve ever been on a waterfall style project, whether it’s called that or not, what actually happens is you just do sort of messy iterations under the covers and you do things like you go back and you revisit a broken design while you’re charging the documentation charge code.

It kind of reminds me of the fact of what people or historians have found that like there were always markets, even in the hard core communist countries, there were always markets going on. Whether they were black markets or they were factories surreptitiously trading vodka for ball bearings because the central planning wasn’t getting the parts where they needed to be. It’s kind of the same thing. There’s always going to be iteration, it’s just whether you actually acknowledge it or you try to pretend that it’s not there.

Yeah, that’s very true. The project that I worked on that was rigidly waterfall, it was a government contractor. We were building a graphics card. We had a team of 25 Electronics Engineers, and 25 software developers. I obviously was on the software team. And our job was to write the reference driver that we would give to NVIDIA and to ATI to build accelerated drivers for this card. This was a really exciting card, the GeForce hadn’t come out yet, you couldn’t do 3D on the card in hardware and we were building a card that would let you do 3D on the card. What we found is that the 2D instructions were synchronous. You could actually say, “Paint this rectangle, blit this image,” et cetera, and they were synchronous.

Then there was this 3D pipe that took -- it was kind of like you send something down, you set up your wireframes, you set up your textures and you set up your textiles, and you said, go. Then you had to wait some random amount of time for the geometry pipeline to finish what it was doing. And so, we had a really interesting bug where what you would do is you would go to paint your scene and so you would 2D, you would blit in your background, then you would send all the commands to render the 3D scene into the 3D pipe and then you would blit. You would compose this image down into video memory, and then you would blit this onto the screen. Of course, what the bug we were seeing was you would click go, [sound] and you get the background and blit it onto the scene.

And the bug was that you would do a bit blit to copy the background to somewhere in memory to begin composing the image. You would start the 3D pipe, and then you would immediately copy the image which had not come out of a 3D pipe yet. So you had basically copied just the background onto the screen and you would say you were done.

Then at some point, asynchronously later, the 3D pipe would fart out all of its 3D data into video memory, which has already been copied onto the screen and it’s lost, and you had no way of dealing with this. And we’re like, “Oh crap! We have a pretty major problem with our hardware. We got to fix the hardware.” And the accounting team said, “Well, we have a problem, the chip is already in the fab. And they have a phrase and it’s a four letter word, the phrase is called, ‘Turning The Chip’ and what Turning The Chip is, is when you say, “We have screwed up our design so bad.”

We know Micron has developed, they’re cooking our chips, they take like 90 days to build from start to finish. They’re building the lithographs and they’re building out all the -- they’re literally baking Gallium Arsenide onto Silicon wafers in the fabricator. And if you turn the chip, you basically say, “Throw away all the silicon you have made to date, go back to the beginning, turn back to the beginning and start over.” And it costs a million dollars in cold green hard cash to turn the chip in the fab.

And so, software found the bug, hardware figured out what was causing the bug, went to management and said, “We have to turn the chip.” And management went to talk to accounting, and then management came back to software and said, “You need to fix this bug in software. You need to figure out a way. You need to make the device driver wait for that 3D to finish.” And we’re like, “Okay.”

Yeah, this was a long side tangent ramble, again blowing our estimate for how the show’s going to go. But the whole point was we had invented the concept of a marble that whenever you did, you could do a synchronous 3D operation by putting a marble in the 3D pipe that says, “I’m beginning a 3D operation.” then you do all your 3D operations. Actually, you don’t put a marble at the beginning, you put all 3D operations into the pipe and then you put a marble in the pipe that says, “This operation ID 41 is done.” And then, you’ve got this bit blit that’s ready to copy the scene into video memory. But it has to wait for this marble to come out of the 3D pipe. And once that marble comes out of the 3D pipe, we know that the scene has been rendered to this buffer in 2D and this can now be just copied very quickly into video memory.

We spent, it was like, I don’t know, like an engineering montage basically. In my memory, it’s all a montage clip now, because I remember all hands company meeting, Engineers, software and hardware shouting over the table back and forth at each other, people screaming, “It can’t possibly work.” Other people screaming that they’d already done it, and then, we all broke up and went back to our separate corners. And we fixed it in software.

But Avdi’s exactly right that we fixed it in software and we build it as a development overrun. It showed up on the report as our software developers are not as good as we thought they were because they were much, much slower at developing this device driver than we said they were going to be. When in reality, it was just a complete oversight on the interaction of the 3D and the 2D pipeline, for the entire team, software and hardware. I’m going to stop talking now.

Let’s talk about success stories for a minute.

No, those aren’t any fun.

Question for the room, have you been on a project that got the iteration to iteration estimates pretty much dialed in? And if so, what can you say about the properties of that project that made that possible?

Have we got any Pivots in the room, Josh? Ex-Pivots?

So, I have one of these examples but it wasn’t when I was at Pivotal. It was when I was working at a big company. I was managing a team doing Java web application development. And the tech lead for the team was responsible for coming up with the estimates for work so we’d get feature requests come in. And I think it was the nature of the application that it was basically an integration layer between the company’s database and just providing a thin UI layer between some functionality on top of the database and the user. So, it wasn’t terribly complicated stuff.

But the tech lead had some little formula in his head where he would go through and look at the number of screens and the number of fields and just ram it through some little spreadsheet that he had. He was really good at coming up with estimates that were within half a day for a month-long project.

Wow!

He was awesome, never letting you off my team. But other than that, I haven’t seen many success stories where it was just dialed in.

[Crosstalk] Go ahead.

I just think it was the nature of the project that there wasn’t anything terribly complicated in what we were doing.

Now, on the other hand, we had a couple large external dependencies. So, I think that our tech lead’s real talent was in noticing when we had external dependencies and figuring out how to estimate how much work that was going to be because from what I’ve seen, external dependencies are usually the biggest unknown factor when you’re doing estimation, and you have to account for the integration techs. Integrating with other system always takes a lot more than you expect it will.

So now, the conceit of Agile, Josh, if I may. I’m about to put a more difficult question to you. The conceit of Agile is that we don’t plan beyond one iteration between a week or two because we are going to develop for a week or two and then, we’re going to make some discoveries. We’re going to hit the Ugh!knowns in the project. Was this guy just magically good at predicting the size of the Ugh!knowns or was he just really, really good at reducing the entire project to knowns, discovering all of the assumptions and discovering all of the knowns, and then forbidding the scope to creep?

I think it was more of the latter. But I think basically, he’d been doing this application for so many years that he had essentially done all this kind of work many times before so it was very easy for him to map future things to work on, to things he’d done before.

Okay. So, he had a large library of cookie-cutters in his head.

Yeah, basically.

So, I have a rhetorical question. I have a question to put to the room and I have what I believe is a good answer for it. But I mentioned in the preshow that I have blown an estimate by a factor of 100 just in the past year.

Actually, I have two questions for the room. The first question is what’s the worst estimate you guys have blown that you’re willing to admit to? And the second one is related to success stories. And that is, how can you get better at estimating?

I think that was the question that was posed to the Rogues originally for this podcast, right? It’s, how can I get better at estimating? So, let me just throw that one out there. What’s the worst estimate you‘ve blown and how do you personally get better? Have you done anything to work on your estimating, and if so, what?

So, I have something that I’ve been working on for about two weeks right now and I estimated a day on it. I’m not hundreds but I’m pretty far off. The main thing is because it turned out that I had to add a whole bunch of infrastructure in order to manage it the way that it needed to be done. And I honestly think that what I really should have done is I should have left that estimate at one day. But I should have gone in and basically added another feature that represented this two weeks of work that build up the infrastructure. Because ultimately then, the problem wasn’t necessarily me estimating, it was my allowing the scope to creep. And rather than doing that, I should really have just broken it down into stories that I could estimate into a day, or two, or three.

Now, did you scope creep or did you make a discovery that in order to build the tip of the iceberg above the water, that you had to go down and build all of the iceberg under water?

Well, it’s a little bit of both. Basically, what’s going on is that I started Backbone.js on this project, and I’ve been porting a lot of the internal logic out to Backbone so that it can display it properly, and manage it, and set up all the events, and because it’s a pretty JavaScript heavy application. And I actually sat down with some guys that are part of the -- I don’t really know how to describe them. It’s my client’s brother in law and nephew who work for a big software company out here.

Anyway, so we were talking about Backbone and they basically said that they wanted this particular model ported over so that you could access the information through Backbone. And so it went from just adding another AJAX call that spit HTML back that did whatever it did, to moving the entire feature over to the Backbone framework and that’s what ultimately caused it. It was something that I would have had to do eventually anyway. So, it was a little bit of a scope creep from them as well as something that I saw that I needed to do anyway and decided to just move into. So, it was kind of a dual thing of discovery and scope creep.

Okay.

Anyway, I think scope creep honestly is one of the biggest things, the other one is the discoveries. But again, if you go back and you put feedback into your list of stories so that you can account for this stuff, then you’re not off by a factor of a hundred, you’re letting people know upfront, “Hey look, this is going to take longer than I initially said.”

Yeah. Avdi or Josh, either of you willing to cop to a horrible estimate?

I wanted to make a comment about something Chuck said where he was talking about smaller stories. I think that it’s much easier to provide estimates for small stories. And one of the actual techniques we use on projects is, or that I’ve used on projects is, if you see a bunch of big stories coming up for the next iteration, you take them and you break them down into small stories. Many times, what I prefer for the size of a story is the smallest story that the product owner could accept. So, do you break it down into a small enough feature that it could be accepted independent of some other feature?

Maybe you have one big story, it was a four point story. And it was, user is able to reset their password, but you could actually write that down into a couple steps of user can request a reset, user can complete the reset. So, I would go and break it down into those smallest possible steps that made sense, and then estimate those things.

So, I’ve tried to do that in the past and there’s a wrinkle that I run into all the time which is that I take a big story and I break it down into smaller stories. And in order to do that, you have to kind of, I want to say you have to implement the story in terms of smaller stories and I get that implementation wrong. Have you run across that and how do you back out of that? Does that make sense?

No. [Laughter]

So, Joel Spolsky says that you can’t estimate something without designing it. You have to decide how you’re going to implement this. How long does it take to add O-F to a project? Well okay, if you know about the O-F gem, then it’s going to take about this long. But what happens if you decide, “You know what? We’re not going to use the O-F gem. We’re going to go ahead and implement it ourselves. We’re going to write the HTTP layer, we’re going to do the requests, dah…dah…dah…dah…” And then, you get into it and you find out that, “You know what? We’re doing all of this in Node.js and we have this asynchronous thing right here that we can just use which means that all of our breakdown of the story is based on some incorrect assumptions.”

Hey Chuck, you should mute.

Yeah. The way the recording works when I record it, I can’t mute on the recording.

Oh, crazy. Okay, understood. So David, I think that the breakdown of stories, I always try and do that along the lines of the actual feature perspective. What’s the user experience? What’s the design of it? And because the product owner, who’s going to be accepting the story and figuring out if you’ve done the work or not, has no clue how you’re building it. He or she doesn’t care about how you write the code or whether you used one O-F library or another, or you build it all from scratch. He just wants to be able to look at the screen and click a button and see if it does what is expected.

So, I don’t think that you really need to guess how you’re going to be implementing stuff a lot of the time when you’re breaking stories down. You do need to understand how you’re going to be implementing things at least at some level when you’re estimating those stories.

Okay. I think that’s the secret thing. My take away from this is going to be, try to not get into implementation details when you give your estimate. I mean, you can go ahead and think through them. But whether you store your O-F token in a cookie or whether you store it in the database, the first thing that you said I think -- I asked this question because I wanted to really highlight what you said, is you don’t break a story down into implementation details. You break a big story down into smaller stories which are still user visible. Would you say that’s an accurate summary?

Oh yeah, unless it’s all like backend chore type stuff. I don’t know. I think that most stories even if it’s backend processing, they are in service to some feature that the user will encounter.

Yeah, okay. Avdi, have you got a -- oh Josh, you didn’t cop to a bad estimate.

Oh.

And you can just say, “I’m not going to.” [Laughter]

But I’d love to. I think I’m going to blow both of you guys. I estimate that I’m going to blow both of you guys out of the water with worst estimates.

Yeah. I don’t really have any worse stories that are amusing about bad estimates. We’ve all made bad estimates.

My bad estimate story is not amusing to me. [Laughter]

I’m sure it will be to us.

But I just don’t know how useful these stories are because everybody, I think that’s pretty much our default state of existence is that we make bad estimates.

Do you remember that episode of Star Trek Next Generation when they find Scotty crashed on the surface of the Dyson Sphere?

Yeah.

Oh, that one! [Laughs]

And he has this conversation with Geordi La Forge, and Geordi’s like, “Okay Captain Picard, I’ll have this done in three hours.” And Scotty is like, “No! No! You can’t tell him that.” [Laughs]

No, he asked him, how long is it really going to take?

Yeah.

And Geordi’s like, “Three hours.” And he’s like, “Oh, I always padded it by a factor of four.” [Laughter]

How else will you maintain -- you did record it.

How else do you get a reputation as a miracle worker? [Laughter]

So, it’s funny. My first job when I was working at Xerox, people on my team were like, “Okay, you got to remember the pie factor. When you make an estimate, just multiply it by pie.” [Laughter]

The rule that I use for padding and honest to goodness, when other people give me an estimate, I heard this as a joke and I laughed, and then I saw it playing out around me and it made me cry. But basically if a developer has less than five years of experience and they give you an estimate, multiply it by two and then raise it to the next larger unit of measurement.

I knew you were going to say that.

So, if they say five minutes, it’s ten hours. If they say two days, it’s four weeks. And the sad thing is that I’ve seen that play out.

Yeah.

It’s surprisingly accurate in some cases.

Yeah. So, Chuck is going to get after us here in a minute to do picks. If I could just take a minute, I have two good things that I can throw out for people for getting better at estimates.

Okay.

You guys can say no. Okay, the first one is just a red flag, if anybody ever tells you two weeks on an estimate, that’s [deleted]. You can bleep me if you want, sorry Chuck, I don’t want to lose our family rating. But two weeks is, translated from programmer ease into plain English, two weeks means I don’t have a freaking clue. And you’ll see people all the time, “How long do you think it will take to implement your own O-F gem?” “I don’t know, two weeks?” And the reason why it’s BS is that we know from doing Agile that you can really only reliably estimate for a day or two, unless you’ve got this mythical ability like Josh’s co-worker.

I don’t think it’s completely mythical.

I believe it’s within the realm of say the top 10% or 15% of engineers to develop over time especially…

I think it’s also within the realm of a well-gelled team.

Okay, that’s fair. And again, especially if they’re cookie-cuttering things that they already know. I’ll cop to that.

So, if you know enough of the factors, then you might be able to tie up to about a week.

I’ve seen this work when it isn’t just a cookie-cutter app too. That’s something I really didn’t get to was I have seen this on at least one team, they weren’t all like mythical hero, rock star developers. I think the only thing it really had going for them was they decided to play the planning game religiously, every iteration have the product owners in there, and have real consensus discussions about their gut feelings of how long something was going to take. Not negotiations but consensus building.

So, two or three people say it’s a two and one person says it’s a five, they have a discussion at that point about what the five is saying, is seeing. And likely, it’s not the whole ticket goes up to a five. Then the product owner says, “Okay. At that point level, that feature would be pushing out some other stuff that’s more important so we’ll push that down to the next iteration.”

But it was a team that was together for a while in the same app. It was not a simple app and it was not a cookie-cutter app, it was a huge complicated app, one of the biggest Rails apps I’ve ever seen.

But they’d been working together on the stuff for a while and they did have a sense of how long things would take. I think once they played the planning game for a while, they were able to actually pretty well dial in on, “Okay. We see that we’re getting 30 points of work done per iteration, so that’s our bar and everything that’s over that, the 30 point mark gets pushed off to the next iteration.

I’ve also seen this work for a little while. It eventually starts to bite you in the butt. But when the team plays planning poker, how many of this is going to be? And all the hands go up around the table with two’s and one guy holds up a five. I’m usually the guy holding up the five and everyone looks at me and says, “Why do you think this a five?” And I say, “Well, we have to integrate this with Chargify and we haven’t written that piece yet. And there’s going to be a whole ton of integration there.”

And there’s this quick, around the table with the customer there, and the customer says, “Well, I don’t want this to be a five. I’m willing to cut the Chargify integration.” And at that point, I say, “Okay, you are willing to say that we’re going to implement an API that is a nolop in the backend. You can push a data, it will validate it and say yes or no, and then send it back to you. But it won’t actually do anything on the backend.” And the client will then say, “Yes because I need this in order to test the iPhone app.” And so, it goes on the card. This story does not include, sir not appearing in this feature gets listed in the credits on the card of -- this does not include Chargify app integration, this is a two point story.

I did find, Chuck, we did this at Public Engines a lot and my gut feel is that it worked for a little while and then it sort of came around to bite us in the butt because they got real used to having two point features for everything and we ran out of things that we could push off. Pretty soon, they came in and they said, “Okay, customer needs to change his expiration date on his credit card. That should only be half a point, it’s just one text field.” And we say, “No, because now, you actually do have to go implement Chargify.” Because we’re literally not allowed to store, for Peace Act compliance, we can’t even store that data on the server. There’s no way we can fake that.

Yeah. And then they go, “Five? WTF?” [Laughter]

Yeah, “For one little text field?” And I’m like, “Yeah, you’re also making an interest payment on the technical debt that you racked up three months ago.”

Okay. So, my worst estimate that I’ve ever blown? I came in late on a project that had been bid $30,000 for six weeks worth of development, this was in 2006. It is still ongoing and they just passed the $5 million dollar mark. I was with them for a year and a half. And when I left, the project had been going for almost two years, and we had broken the $1 million mark while I was there.

If you’re listening at home, kids, do not let the Project Manager and the investor be the same person. Because basically, we coined the term ‘Feature Creep’, the features weren’t creeping, we had ‘feature gallop’. This guy would call me and he would call everyday and we would have an hour long phone call. I have in my journal, I have a log, a 57 minute phone call in which 121 features were added to the application.

No way.

Just insane, insane, insane. And he kept firing developers that couldn’t keep up with his technical debt. Okay. So, we need to get into picks. So, I’m going to give you, the listeners, the best possible way that you can get better at estimation, and that is to estimate your estimating.

If you are not, the most important part of planning poker is the retrospective at the end of the sprint. If you give an estimate, say this is going to take me eight hours, and then write it down somewhere. You actually have to write it down or it doesn’t count because your brain will fudge the numbers later to make it look better. But write down, “I think this will take eight hours because X, Y, and Z...” just two sentences. And then, at the end of eight hours, when you hit the estimate, write where you’re at in the project and why you’re not done, or why you finished early. And basically say, “Well, I learned this, this, and this.” And if you’re not done, estimate how much is left to go and why you think it’s going to take that long. And just close the feedback loop. All you have to do is give your brain data on how it estimates.

I don’t do this often enough but I have found that my confidence, the degrees of standard deviation on my estimation has improved by an order of magnitude. Now granted, I have blown an estimate by a factor of 100 this year. But ten years ago, I would blow estimates by a factor of 10 every single week. And now, it’s rare that I blow an estimate by more than a factor of two or three. I’ve blown two or three by 10 this year and I’ve blown one by 100 this year, and next year, I’ll blow one by 100 again. But if you focus on your estimate and go back and look at what you did, give yourself data.

Give your brain data and your brain will adapt and improve.

Alright.

That’s my advice.

Thank you, Dave.

This has been Dave’s Software Advice Hour with Chuck, Avdi, and Josh.

Thank you for sitting at my feet and listening to me expostulate.

Alright. Well, let’s jump into the picks.

That’s what they call that? [Laughter]

Is that a word?

Expostulate?

If so, it’s my pick today.

Do you dare to refudiate it? [Laughter]

Expostulate, I believe, is the active verb of exposition.

I thought it had something to do with farting. [Laughter]

When I do it, it does. [Laughter]

I was afraid of the ‘sitting at your feet’ part of it.

It definitely has something to do with farting. The definition of expostulate is, Verb: To express strong disapproval or disagreement.

Dave, you’ve got hot air coming out both ends, is that what you’re trying to say? [Laughter]

What do you think of that? [sound] [Laughter]

Okay, real picks. Picks, picks, picks before we get too far on this one. Alright, I’m going to go first. I never do that, I always make somebody else go first so I’ll do it.

So earlier, you probably heard my two-year old come in and then Josh prompt me to mute. And I said, “I can’t mute.” Then I realized I have seen mute buttons for microphones like mine. So, I have just barely ordered a Rolls Mic Mute button. And when it gets here, I should just be able to press on the button and you won’t be able to hear my two-year old, or me telling her to get out. [Laughter]

Nice. I mean, nothing against your two-year old, I’m saying that’s nice and I want to do it from a technological perspective. I’ve met your two-year old.

I know you have.

Yes, they’re good kids.

Ah, they’re cute. Good, sometimes. Anyway, my other pick, my wife got me a Kindle Touch for Christmas. I had an iPad before, but I will tell you that reading on the Kindle is so much nicer, and so much easier than reading on the iPad. And so, if you hate reading on your iPad like me, then go out and get a Kindle. It costs $100, super nice. Anyway, it just worked out really, really good for me. Anyway, I’ve been reading books like crazy just because it’s easy on the eyes and nice to do.

Anyway, with that, we will go on to Avdi.

Let’s see. It just occurred to me that I don’t think I’ve ever picked liquor which is weird because I like liquor.

And you drink some of the most colorfully named beverages I’ve ever seen tweeted. [Laughter]

Thank you, thank you. And realizing this, I realized I basically have -- now that it occurred to me that I can do that, I basically have picks for until the end of time now. But to just pick one, one of my presents this Holiday Season from my wonderful wife, it was one of my very favorite Bourbon’s which is a Bourbon called Blanton’s. And my wife -- I love my wife’s description of how it tastes. She says, “This tastes and smells like a Civil War Museum.” [Laughter]

Nice.

And I think that’s pretty bang-on. Really good stuff.

I love the gun powder notes.

[Laughs] Yeah. So, Blanton’s Whiskey. And also, I was looking through the picks and I know we’ve mentioned this but apparently we’ve never actually picked it. Gary Bernhardt’s ‘Destroy All Software’ screencasts, unless I’m missing something, have not been picked. So, I am going to take that one. He’s been turning out just some fantastic material on testing, on object-orientated design, on using your editors better, patterns, the whole nine yards. Fantastic stuff, check it out.

Alright, Josh?

Okay. So, my first pick is, I wouldn’t actually call it a pick although it’s just a little treat that involves the most interesting man in the world. I’ll just put that link in the notes for people.

And then, okay, I actually have some picks. One of my picks is George Takei. You may know him as Hikaru Sulu from the original Star Trek series and many other appearances. I just think he’s become one of the funniest guys on the Internet, his Twitter and Facebook updates are often epic.

He’s just really worth watching for a laugh a day. So, George Takei.

I have a question about George Takei. When did he come out?

That was years ago.

Was it? Okay. I did not know he was gay until last year, he made a quote. The iPhone came out with an app called Fruit Ninja and he said, “I am the original Fruit Ninja.” [Laughter]

And I was like, “What the heck is he saying?” [Laughter]

It wasn’t that long ago. I remember, it was only like a couple years ago I thought. I remember it being a big news at the time that he…whatever.

Yeah, whatever. But he’s been, I think, great on the political scene. If you like socially liberal politics, he’s been great on that front. He did one of those, it gets better videos and he’s done a lot of stuff in support of gay marriage and other interesting causes but I just think he’s funny. [Chuckles]

I want a site where he just reads things, anything I don’t care, a newspaper, technical manuals. I just want to listen to him.

Nice. Anyway, George Takei. I’ll say again, I don’t know if I‘ve said this on the air but I’ll say it again. My ultimate fantasy Internet mash up is some science fiction project, written by Josh Whedon and staring George Takei and Neil Patrick Harris.

[Chuckles] Okay.

It’s all I want. So my other pick is, I cook a lot, I like cooking stuff so my pick is a cookbook. And I’ll disclaim here that there’s a little bit of nepotism involved here. So, the authors of the cookbook are my niece and her boyfriend. But it’s a super awesome cookbook so I don’t feel any shame in recommending it. It’s called ‘Make It Paleo’. The Paleo diet is basically grain-free, gluten-free kind of diet. Heavy on meat, vegetables, some fruits, no refined sugar. And this is just an awesome cookbook. It has accessible ingredients and beautiful artwork and really well-explained recipes. I’m really proud of what they’ve been able to do throwing this cookbook together and like amazingly high quality in a short amount of time. I’ve shown it to a bunch of friends and they all love it. So, I feel good about recommending that to people.

Except they should have put George Takei on the cover.

That would be awesome. I will talk to them about the next edition. [Chuckles] They’re already working on the second cookbook, I think. So, we’ll get George Takei on there. Okay. So, ‘Make It Paleo’. And they also have a blog called Primal Palette where they do recipe updates every week and that’s worth checking out too. That’s it for me. Thanks.

Alright. David, go ahead.

Okay. Three books real quick. One, absolutely directly on topic, ‘A Discipline for Software Engineering’ by Watts S. Humphrey. This was a college textbook from like 1998 and it’s like 500 pages. I recommend that if you can find it at a college bookstore or used for a couple of bucks, pick it up. This is highly recommended for those of you out there who are absolute left brain, anal retentive wonks when it comes to writing software because he basically defines what he calls the personal software process and it’s all about getting better at estimation.

If you don’t want to buy the book, basically what he says is, take a programming problem, write down your estimate, then go write the code, and then come back and review your estimate and make a little worksheet and score yourself on it and just keep doing this over and over again until you get better. But I don’t know if I recommend buying the book. It’s certainly dated, it predates Agile entirely and he’s from the Waterfall School of Thought. But his little bit on the personal software process where you specifically focus on improving your estimation is a real eye opener, absolutely fantastic.

General programming, I thought for sure I had picked this before, I’m going to pick it now. ‘Class Construction in C and C++: Object-Oriented Programming Fundamentals by Roger Sessions. This is a fantastic book. If you have ever wondered how object-oriented programming works at the nuts and bolts level, he sits down with a C compiler and you spend the first half of the book, you really do have to know your C, but he basically does object-oriented programming in C using structs. And you have to build your own vector table, and you have to build your own, basically everything you need to make the OO work. And it’s not until he finally gets to the section where he starts talking about how do we do inheritance that he says, “Okay. We’ve finally reached the limits of C using pre-processor defines. We can’t do inheritance with this. We’re going to have to break down and go ahead and do C++.”

But by the time you’ve gone to C++, you now know what all of the underpinnings and fundamentals under the hood of how objects work and everything else. Once you have learned how a vector table is implemented in C, you will all of a sudden just kind of figure out how pretty much every other OO language out there, short of maybe Lisp or JavaScript which is more prototype-based, handles their internals.

The Ruby model was baffling to me. I was trying to figure out how the vector tables lined up until somebody stood up in a Mountain West Ruby Conf presentation and said, “Well, the super class of the meta class is the meta class of the super class.” And I went, “Oh, of course!” And everyone else looked at me like, “What, of course? We’re still trying to figure out if that sentence, the vessel with the pessel is the flagging with the dragon.” They were like, “What the hell did he just say?” And I’m like, “No, he just said that there’s two separate vector tables and that they overlapped each other.” And they're like, “What?” And I'm, “Just go read the C.” The book by Roger Sessions will explain it to you so well that you will just get OO at the nuts and bolts level ever after.

And my third book pick. I love Sir Terry Prachett, the Discworld novels. I think I may have picked him or mentioned him in the past. He has been diagnosed with early onset Alzheimer’s which is about the worst possible disease that you can have if you’re an author. He is my absolute most favorite author. I would recommend books to him without even having read them which is what I’m about to do. And I basically, when he announced that he had Alzheimer’s, I realized that his writing career was coming to an abrupt end some year soon. And so, I took his most recent book and I put it on the shelf and I said, “I’m not going to read it.” And then when he wrote -- basically, I’m going to read his last book after he stops writing or after he dies.

Then he wrote another book. So, I put that one on my shelf and I took the other one down and I read it. Then, he wrote another book. And sp, I put that one on the shelf, took the second one down and read that one. He has just written a book called Snuff, it’s a Captain Vimes novel. If you’re a Vimes fan, he’s one of my favorite recurring characters in the Discworld right after Tiffany Aching, which was the previous book, by the way.

And long story short, he is on an experimental medication that is holding his Alzheimer’s at bay. And so, we have every optimistic hope that Sir Terry will continue writing books for years to come. So, I’m actually going to go break down and go ahead and read Snuff now, rather than waiting for it to be his last posthumous work. Those are my picks.

Alright. Well, thank you, Dave. That covers all of our picks. Really quickly, we will be reading Land of Lisp for our Book Club coming up in February. So, go pick it up at LandofLisp.com.

Also, you can leave us a review on iTunes and you can leave comments on the blog at RubyRogues.com.