var self = justin();

Software Developer Teammate

A place to remind my future self of what I've learned and experienced. That means both my successes and failures.

Mistake Driven Development - Estimations

Mistake Driven Development, or MDD (because we need another TLA in our lives), is my thought process on how I grow as a human both personally and professionally. The basic idea is that I, as I'm sure others do, learn best after making mistakes. I can be told the right way to do something and I can follow the approach, but it never really sinks in until I see what happens when I don't do it. The reason I care about things like dependency management or domain models is because I've felt the pain of not using them. It's the pain that drives me to do better. It's the pain that gives me an opportunity to improve. Were it not for the pain, I'd never want to change. For me, I have to make mistakes before I can grow.

For me, MDD doesn't stop with my technical skill sets. When I married my wife, we were both pretty young (21). I hadn't had a chance to really get myself together and now I had to be a husband. I made several mistakes (we both did but I'd never tell her that) and I felt pain. Sometimes I felt that pain several times because I can be slow learner. But eventually, I find that I want to stop feeling the pain enough to change my ways and that's always when I grow. We're still young and have a lot of years to continue to grow, but I can at least look back as we clear our first decade and see improvements.

News Flash: I suck at estimates

In my professional, I sometimes try to anticipate what my client or boss wants to hear and craft a pleasing response that orbits the truth instead of landing on it. This most always manifests itself in over promising. This is an area of particular interest for me. I've felt the pain of over promising (often in the way of low balling estimates) time and time again. I've walked that emotional path so many times that my feet will take me there without any conscious effort on my part. In other words, I'm so good at doing it that I don't realize I'm doing it until it's too late.

One mistake started out the same way. A client was pressuring me for an estimate. I gave one and she didn't like it. So we "negotiated" until I walked out of the room with a familiar sense of foreboding. As a human, I suck at estimates in general. Put me under the pressure of some forced negotiation (whether real or by my own imagination) and by the end of it I've probably blacked out halfway through and temporarily made my client happy at the expense of several future sleepless nights.

Before I go any further, in no way am I attempting to blame a client for my lack of a firm stance. A client's job is to maximize value for her company which includes motivating those who work for/with her to deliver quality content quickly. As an executive for the company, she is expected to drive success hard.

I have a theory as to why this happens. I think I subconsciously simulate the client interactions with a variable estimation. For example, maybe the simulation starts with an estimation I feel comfortable with. If I think she'll blow up, I'll re-estimate the work with the goal of reducing the length of time required. The problem is that this distorts my vision to the point that I began to over estimate my capacity or ability. I also see this as a self fulfilling prophecy of sorts. If I'm too afraid of what the client will do when I say 6 weeks, I'm going to justify a way to myself to say something less.

This will lead to a new estimate of 5 weeks. She still won't be happy but I'm sure if we work really hard we can possibly get it done in 4 weeks. So I can just tell her 4-5 weeks. Cut to me delivering the estimate and the only thing the client hears is "4 weeks". Now she doesn't know that I've already tried to cut through the "what if things go perfect" scenario and thinks she can make me work harder to get it done faster by imposing a deadline. Before I know it, I'm walking out of the meeting and the client has used her knife to carve a giant X on a delivery date three weeks from now... Mother Francis.

So what happens next? I get myself and the team pumped up all the while hoping my face doesn't betray my confident facade. The familiar anxious feeling sits in the bottom of my stomach as if I had extra servings of stone soup. For the next two weeks, I ignore the signs while confidently thinking that we are going to deliver a miracle (with a few swishes of pepto-bismol added for good measure). The last week rolls around and it looks like we are really going to do it. But then something happens, like it does every time. Something happens in the story that we didn't foresee, production blowa up and pulls half of the team away, or the client introduces a "simple" change.

Two or three days before we reach the giant X on the calendar, I realize it's hopeless. I began to think that if I work the next 72 hours, ignoring distractions like sleep, food, or time with my beautiful wife and son, we might have a 30% chance of making.

Reality quickly sets in and I began customizing my most dreaded email template. You know what it is: the "we need to delay our release" one.


I'm so tired of this. I'm ready to start making changes that will help prevent or control situations like this in the future. I've felt the pain enough now that I'm ready to do something about it. This is a great opportunity to let my mistake drive my own development.

Note: my point isn't to make perfect estimate, I don't even think that's possible. My point is to work to create more realistic estimations all the while being honest with myself and my client.

So here are some things I'm going to start doing:

Stop giving estimates to the client the first time I'm presented with the scope of work

This seems like a very obvious thing, but the problem is that I would forget about my previous mistakes and over estimate my own ability. Even if the scope is extremely well defined and I know the code base like I know my refrigerator, taking a moment of pause will allow me to clear my mind and provide time for historical reflection. Afterwards, I'll approach the client with an estimation completed free from pressure.

Stop giving perfect world estimates

If my physics classes taught me anything, it's that there is a perfect world that exists where there is no air resistance and all cows are spherical. Also, in this perfect world, nothing unplanned ever happens. My team suffers no illness, family emergencies, or destroyed laptops. We make no incorrect assumptions and introduce no bugs and every solution comes to us immediately without needing to ponder it for days. Maybe this world does exist... however, it's just not the world I live in.

The only constant is change. Life is unpredictable and I need to remember that when I'm thinking about much time we'll need to complete something. While my client might be sympathetic to one of my teammates needing to take a week and half off because of a death in the family, she doesn't want to hear that as an excuse for why we are late. My estimates need to take into account the unknown. Some people call this padding, I'm calling it being realistic.

Spend more than 5 minutes on the estimate

Sometimes, I'll think that I know the problem and solution set so well that I don't need to dig deeper. Making estimates within a really short period of time is like trying to quickly eat a loaf of bread with a rock hidden inside. When you find that damn rock, it's going to hurt like hell.

Involve other people

I need to stop thinking I'm always the right person to make the call on how long something will take. I might be the lead on the team, but I'm not the best. It's not my job to know everything. It's my job to utilize my teammates' strengths to create a cohesive tandem of individuals. We should be estimating as a team, not just me. Again, this seems very obvious, but I'm admitting to making this mistake.

Stop thinking everyone has my strengths and weaknesses

Maybe I really can do something in 3 days. But does that mean everyone on my team will take the same amount of time? I can crank out some front end code pretty dang quickly. But you need me to write a complex SQL query? Hello Google (ok, really it's StackOverflow). Another person on my team might happen to be the person who has to do some CSS work and she might not be very good at it. 79.1% of all developers are intimidated by CSS... yes, I just made that up.

This isn't an exhaustive list by which I will use to do better; it's just a start. After I've given these seeds some time to bear fruit, I'll re-evaluate and see what else I can do better with regards to estimations. I'm also very open to any suggestions others have. So, if are one of the 4 people who have read my blog, please give me some tips and advice you think is helpful.

comments powered by Disqus