It’s okay to just do the work

You don't always have to build a long-term sustainable solution to every problem. Sometimes you can just get it done.

Get it done

We once found a bunch of user accounts that failed to cancel. The bug wasn't interesting, once we found the issue it was quick to fix. But what do you do with all this production data that's in the wrong state?

You can't rollback the database because this wasn't a new issue. Bad accounts going back several months were interspersed with accounts that are valid. You can't fix data directly in the database either because the change needs to run side-effects in the application layer. There's a bunch of stuff that happens when you cancel an account.

We all got in a meeting and started to debate: Do we build a CLI script? Make a button for someone to press? How do we identify which accounts need fixing? What's the best way to import a spreadsheet of names? How do we make sure it's done right?

After an hour of back-and-forth our PM goes "You guys are driving me crazy. There's like 100 of these people and it takes me 3 seconds to fix each of them by hand in our admin tool. I'll just do it myself. This conversation isn't worth our time"

Fueled by pure exasperation, she then spent 2 hours clicking around the admin interface and solved the problem. Zero code, just work. It was the perfect solution.

Don't overthink the work

Not everything needs to work forever. It's okay to solve today's problem and worry about tomorrow's problems tomorrow.

Titus Winters says in Software Engineering at Google that "Software engineering is programming over time", and he's right, but often software engineering is about finding a solution that barely works. Not every problem is worth the full might of your engineering team.

Would manually cancelling user accounts work at Google scale? No, there's too many. Would it always work at startup scale? Nope. Even cancelling a few hundred by hand would be tough. Was it worth the PM's time? Probably not. She's pretty busy.

Was 2 hours of tedium worth avoiding the full overhead of writing a story, adding it to the sprint, deploying all the engineers, dealing with code review, and all the validation that comes after? Damn right it was.

Once a pointed story is on the board, it takes at least 4 person hours to resolve:

• review story to make sure it's ready for the team
• estimate and point the work
• meet to plan your solution
• do the work
• review your code
• validate in a safe environment
• deploy to prod

For small stories these steps don't take a full hour. But your whole team is there and their time adds up fast. A 10 minute meeting between 6 people makes 1 person-hour of work.

Before you do all that, evaluate what size problem you're even solving. Anything less than 4 hours isn't worth putting on the board. Or at least it's not worth using the whole process.

Cheers,