Avoiding Parkinson's Law

Parkinson's Law tells us that “work expands to fill the time allotted for its completion” - meaning the more time you have the more time things take.

And the origin story is about a woman who had to send a postcard.

For many people, that may be a 3-minute task. We are busy, so we don’t want to draw it out.

But this woman spends an hour looking for the exact right postcard, another half hour looking for her glasses, 1.5 hours actually writing the card, 20 minutes deciding whether or not to take an umbrella along on her walk to the mailbox etc. In the end, sending a postcard takes her a full day, instead of 3 minutes.

And I’ve often caught myself falling victim to Parkinson's Law.

Give me three days to write a proposal for a client, I can do it.

Give me one day to write a proposal for a client, I can do it.

Give me 3 hours to write a proposal for a client, it’s tight.. but you know what? I think I can do it.

An example of Parkinson's Law

So you have to choose a technology framework for a new project, a relatively simple project, an online inventory system with an administration interface.

You’ve previously used NextJS with much success, but lately, you’ve been hearing a lot of talk about Laravel, and are interested in giving it a try. You have 6 weeks until you need to start the next project, so that seems like enough time.

You can imagine what happens here, where previously you have the core of the project scaffolded in 2 weeks, this time you only accomplish

1. Researching Laravel boilerplates, but decide to start from scratch to learn the most
2. Learning Docker, as this ships with the default Laravel project and you haven’t used it before
3. Trying different authentication packages,  as the ecosystem is huge and there are many options
4. Going down a rabbit hole on Laracasts, learning about Pest PHP testing framework
5. Getting stuck with PHP syntax, as you haven’t used it for a few years

You get the picture.

You’re not too stressed at the start because you have 6 weeks, but as time rolls on, you're not where you want to be. Perhaps you bit off more than you can chew. Sure, you learn some new tech, but it’s rushed and stressful - and importantly, even though it seemed like a long time, you ended up going 2 weeks over the 6-week deadline, which ate into the start date of your next project (making that one unnecessarily stressful also).

Learning is an essential part of life, especially in technology, but it’s important to choose your battles, and understanding our brains - and that Parkinson’s law exists in all of us - can help get your priorities in order.

For example, you could stick with NextJS, and pump this project out in 4 weeks in your usual high quality in the ecosystem you’re comfortable with. Then you have 2 weeks up your sleeve before your next project - a perfect time to start learning Laravel without any pressure.

How to avoid Parkinson's Law

If you know humans have a bug, where we “fill the time available” - then we can try and squash this bug. As developers, debugging is what we’re good at right?

Often it’s easier to debug a piece of code than it is to debug your own behaviours and habits. But to get work done efficiently, and not fill up the time available, these hints might help.

1. Always have a crystal clear scope

If you don’t have a plan, you’ll never know if you’re on track.

Think deeply before coding, and run all edge cases and question past your client in order to agree on what should be done. I capture super detailed user stories and acceptance criteria in Userdoc (yes that’s a shameless plug) and then get my client to approve the requirements even before starting development.

This helps mitigate the “oh I just realised this…” and “We also need to handle that” which can often occur, and instead makes you more focused on exactly what was agreed.

2. Estimate tasks, and try and stay within the range

Developers traditionally hate estimates, but they serve one good purpose - reminding you how long you thought the task would take.

If the postcard-sending lady (in the origin story of Parkinson’s’ law) had estimated the task would take 30 minutes and planned her day around that eventuating - then she wouldn’t have taken 1.5 hours writing the message… or at least she would have had to mentally acknowledge that she’s taking considerably longer than planned.

It’s ok if things take longer - as long as you are actually ok with that, and you are mindful about the time spent.

Timeboxing techniques have worked for centuries to keep you mindful, and methods like Pomodoro have served to get the most out of the time you have and make you more aware of what you are doing right now - compared to what you should be doing.

3. Do what’s most important first

If the project you’re working on is an AI house blueprint generation platform - where you upload photos of houses and it uses AI to predict what the blueprints and floorplans look like - then just straight into generating the AI blueprints.

Although starting with the server setup, the DB structure, then the user authentication and admin website etc might seem more of a natural starting progression - it’s not what's most important… it’s fine to do things out of order and put the important parts first.

To avoid filling the time available, you want to start with the most important, most risky components, focusing on getting them up and working as required, but saving any bells and whistles to the end (assuming there’s time that is).

4. Don’t get stuck on trivial edge cases

It’s hard to know what’s trivial in a project, as it varies from agency to agency (and client to client), but a good example might be trying to get a website to be pixel-perfect on a super old version of Chrome on Android. Sure, it’s nice to have - but if it’s literally going to affect maybe 0.5% of the users of the website, that should only be something you tackle if the project is delivered perfectly, there are no other improvements, and you’re under time and budget.

My mentality is to log the small bugs and improvements in your project management tool, but first, get the feature done. I love the saying “make it work make it right make it fast”.

You can then triage the issues and decide when and if they need to be dealt with. You don’t want to spend an unplanned day on something that actually adds little value to the project, so always asking yourself “is this trivial?” or “is this a super edge case?” is a good way to detect that it’s occurring.

Note: I’m not encouraging delivering buggy code by any means, I’m encouraging being self-aware of what’s the most important - and making intentional use of the time you have.

Sometimes it’s fun to spend a couple of days tinkering with new technology, or getting sidetracked going down a stack overflow rabbit hole for a few hours  - and often that’s how we learn and grow.

But if you’re trying to increase productivity, and trying to hit your project deadlines (whether they are self-enforced or enforced by your clients) - then integrating the techniques above might help you out.