Software Development and Lessons from Jigsaw Puzzle
This week I’ll share an analogy that triggered a lightning talk back in 2018; Jigsaw and development.
The Jigsaw Puzzle Process
I’ve solved some jigsaws in my life. I used to be that - disgustingly - good where I could pick up a random piece and slide it into its position on a single try. “Used to” as I haven’t tried that lately on a hard jigsaw puzzle. Back in middle school, I completed my first serious puzzle of 7K pieces. Later on, right before university, I completed another one of 3K that still stands on one of our house walls.
Finally, we tried our luck with my wife - then girlfriend - on a 13K jigsaw puzzle until we dropped; Who would want a 13K beast on their wall? Not to mention moving it to a different place!
Of course, this passion is passed on to my kids, we tried our luck with some awesome magic puzzles during the quarantine, along with some random 1K and 1,5Ks that we occasionally solve for fun.
Shared the above just to say that there is a process in Jigsaw puzzle solving that goes like this:
Check the pieces and flip everything so that it’s visible.
Divide by a theme based on the puzzle topic, colors, unique structures represented, etc.
Build corner pieces first to frame your jigsaw puzzle.
Pick a specific theme to work on and focus on solving that part.
Approximately at 60 - 70% of completion, you feel confident to start filling up the spots seemingly randomly. In practice, by now you know the whole puzzle so well that you instantly identify where each piece goes.
Fix the f***k sky/single-color areas. This is the hardest of tasks and I always - always - leave for last! Still, if you master your skill, e.g. checking piece shape, the task can be easier.
Jigsaw Puzzle and prioritization of software development and software releases
1. “Check the pieces”
In the initial step, we try to understand the problem to a good point that we feel confident about the visibility we have of a possible approach or solution. We share the plan - and visibility - with everyone who will be involved in the development or release of that software.
Essentially, we define the landscape and areas that we will cover and share that with all the affected teams; those might include engineers, marketing, and customer success as all will have some say and use of the final result.
2. “Divide by theme”
We now know the full scale of what we’ll work on. We haven’t built anything just yet, but we can identify themes and different areas to start working on, e.g. the reporting page, or the user assignment page.
Defining these themes we also see their scale against the whole, thus their importance in “seeing the bigger picture”. That importance - specifically for development - will help us put each theme to its right proportions and essentially prioritize working on that.
In the jigsaw puzzle analogy, if there’s a big figure or building that’s dominating it will hold way more pieces; thus more important! We know that by completing that we’ll 1) get a better sense of the whole, and 2) eat up a lot of our time solving all those pieces to see the result!
3. “Build the corner pieces”
The analogy here is that “corner pieces” support the whole jigsaw structure; like the core foundations do in software development. You will need the proper infrastructure, a database, a framework, and some key page layouts to be in place so that everything else will bind on. You will need to frame what you build.
For software development, “corner pieces” are defined in your first step where you check the pieces. Based on the visibility you have in the first step, you also know what are the corner pieces.
[*]Putting an asterisk here for later reference!
4. “Pick a specific theme to work on“
With the foundations in place from Step 3, you can now start working on the first prioritized theme the team decided. You will now need all the pieces to match and define the final vision you imagined in Step 1.
Like in jigsaw puzzles, if there are too many of you working on the project, you can split up into smaller groups to take over different themes: “We’ll work on the main house, can you two take over the surrounding trees?”
Like in jigsaws, if more groups are working on different themes, there comes the time of the big merge! Someone must shift their puzzle construct to fit with the other piece!
Step 4 is where the core of development and collaboration takes place.
5. 60-70%: Confidence to fill up what’s missing
If the same engineering team builds the whole feature, there comes a point where everyone feels confident to add a missing part that’s right in front of them! “I saw that we never handled this error case. Based on what we’ve already discussed for the feature, I built this”
Like jigsaw puzzles, this is the point where you see work speed up! When everyone feels confident with the subject and current work, they can take initiative and build what’s missing.
Solving jigsaw puzzles as a team is a time of frenzy solving with many hands holding a different piece - confidently - crossing each other to put pieces at their right slot. Everyone is happy and cheerful, even engaging in small talk.
6. Fix the f***ing sky!!
Everything that’s tedious and mundane in development - that we leave for last. That’s the boring part where progress is slow and excruciating but vital for the whole work to be completed! Testing out features, improving the performance of some functions and page loads, improving copywriting, and enhancing the experience with micro-interactions... you name it and it’s here!
In a jigsaw puzzle, you can clearly see the image created even without that f***ing sky!! Yet, when the sky is complete you get a sense of fulfillment and the whole jigsaw shines!
[*] The asterisk part: The huge differences between jigsaw puzzle and software
Unlike jigsaw puzzles, software development functionality is not finite, there are no corner pieces! When you are done you will not end up with a nicely corner-framed jigsaw puzzle! All pieces can be extended further for more features and functionality to plug in as a second phase!
Additionally, software development is expected to change and adapt to new needs that you didn’t see through when you first “checked the pieces”. There’s no need to frame the final piece. It will surely change; It will surely extend, or have some parts dropped.
That’s it, that’s the post…
The jigsaw puzzle analogy is NOT limited to software. You could apply the same principles and framework to most big collaborative or solo projects.
The jigsaw analogy and way of working for software is something I lean into a lot. Here’s a longer piece on the same topic.
If the specific analogy doesn’t work for you, please keep the following from this post: Find a framework that will help you break down work into smaller - more manageable - chunks. The important thing is to stop feeling overwhelmed and be happy with the progress you make.
Last week I didn’t post anything as I was playing around with customGPTs! It seems like my dream of an AI personal assistant - mentioned here - trained in my content will be a common thing soon, for better or worse 🙂🙃!
Some interesting reads from these two weeks:
These two very interesting podcasts from Lenny’s Podcast:
A must from AirBnB’s co-founder on how to re-calibrate a whole company: https://www.lennyspodcast.com/brian-cheskys-new-playbook/
Bill Carr talking about Working Backwards: https://www.lennyspodcast.com/unpacking-amazons-unique-ways-of-working-bill-carr-author-of-working-backwards/
This great/simple explanation of how LLMs work (I can share that with my kids and parents!): https://www.theguardian.com/technology/ng-interactive/2023/nov/01/how-ai-chatbots-like-chatgpt-or-bard-work-visual-explainer?utm_source=substack&utm_medium=email