Lesson learned: Things I Thought Would Take a Day

There are certain phrases that should probably be banned from software development. Near the top of the list is, "That should only take a day."

I've been in software long enough to know better. I've also been in software long enough to continue saying it, usually with complete confidence.

The latest example started with what looked like a perfectly reasonable request: "Can we just add a few notifications?"
‍

Now, as someone with (however unlikely) years of experience in product development and leading a development team, I'd like to tell you that alarm bells immediately started ringing. Alas, they did not. My reaction was closer to, "Yep. That's easy enough. Coupla emails. Done. We know how notifications work."

My next step is usually to scope out the idea and get a sense of what might be required. The first hour was fantastic. The second hour was educational. By the third hour we had discovered permissions, workflows, reporting implications, mobile considerations, accessibility requirements and approximately two hundred reasons why a simple notification was so much more than simply providing a notification.

This happens more often than I care to admit.

In fact, if I look back over my career, there is an interesting pattern. The work we thought would take six weeks generally took six weeks. The work we thought would take six months generally took six months. The work we thought would take one day has occasionally endangered entire quarters.

I don't know why this is. I assume it's some little joke software development likes to play.

It's a bit like deciding to do a quick tidy-up in the shed and suddenly finding yourself sitting on the floor four hours later, holding a power drill you haven't seen since 2017 and wondering where the afternoon went.

The thing I've slowly learned is that software isn't really about building things. It's about discovering things. You start with an idea and then you find the exceptions. Then you find the exceptions to the exceptions. Then someone reminds you of a customer requirement from three years ago that everyone forgot existed except the customer.

At some point during this process somebody inevitably asks, "Whose idea was this anyway?"

A dangerous question. There is a 50% chance it was probably me.

What I've realised over time is that the projects that cause the most pain are rarely the genuinely difficult ones. They're usually the ones that looked simple on day one. The moment you think you've already understood the problem is often the moment you stop asking questions, and that's normally when software development decides to humble you.

Past Brad and current Brad have a strained relationship.

Past Brad was very optimistic. Past Brad loved shortcuts. Past Brad thought documentation was something Future Brad would handle. Future Brad, as it turns out, is now Current Brad, and Current Brad has some feedback.

The funny thing is that despite all of this, we've actually become much faster at building things over the last few years. Not because we've magically become smarter. Not because we've doubled the team. And definitely not because software suddenly got easier.

We've become faster because we've gotten better at asking questions before we start and the team have got better at saying no.

Why do we need this? What problem are we solving? What happens if we don't build it? Is anyone actually asking for this?

Those questions sound boring. They are not.

A ten-minute conversation can save ten days of development. A good decision can save months. An avoided feature can save everybody's sanity.

One of the great surprises in my role is discovering that productivity isn't always about getting more done. Sometimes it's about not doing the wrong thing in the first place. I've found that when a piece of work is genuinely important, spending a little longer understanding it rarely slows things down. More often than not, it saves time later. Not always, but often enough that we've learned to respect it.

Which brings me back to the new notifications.

The notifications eventually got built. Of course they did. But it wasn't really a notification anymore. By the end it had become a feature, several workflows, a handful of reports and enough testing scenarios to keep everyone entertained for a while.

In other words, a completely normal day.

And that's probably one of the first lessons I've learned in my role: if someone tells you it'll only take a day, don't panic.

Just quietly clear your calendar.

‍

Lesson Learned is a collection of stories, observations and experiences from the people behind YakTrak. Simply stories worth sharing.

‍