POST

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.

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

I've been guilty of trying to anticipate what my client 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 would take me there without any conscious effort on my part. In other words, I was so good at doing it that I sometimes didn't realize I was 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 directness. 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 developed a theory for why I've done this. I think I subconsciously simulate the client interactions with a legitimate, 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 overestimate 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 blows 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 kids, 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.

Enough

I eventually got tired of this. I was ready to start making changes that would help prevent or control situations like this in the future. I had felt the pain enough now that I was ready to do something about it. This was 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 started doing:

Embrace the suck

When I was a kiddo, if I ever lied to my mother, I would be punished twice as hard (doing the bad thing I lied about + lying). If I have tough news for a client, I embrace the suck and set the expectations from the beginning. Over time, I learned techniques of delivering bad news in ways that weren't so terrible including presenting options for remediation and giving the client a chance to make a business choice regarding the matter.

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 we live in.

The only constant is change. Life is unpredictable and I need to remember that when I'm thinking about how 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.

Take my time

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.

Break it down then break it down more

We suck at estimates, but we suck gloriously worse the larger the workload is. Breaking the work down into smaller items, taking the aggregate then applying overall ranges has been much more effective for me.

This isn't an exhaustive list by which I use to do better; it's just a start.

But Agile... Scrum?! What about using velocity? Why estimates?

I love Scrum and Kanban (each in different scenarios) but when I'm working on an estimate for a client who wants to know how much something is going to cost before they sign the statement of work, sometimes you've just gotta estimate.

Maybe some of this resonates with you... maybe not. In the end, this is just me pulling back the curtains and showing how I took some mistakes I made and turned them into growth opportunities.