Software development is an enigmatic field to people who are not themselves software developers. We type strange words into computers and it makes pixels on someone else’s screen move around. Very little of what we produce can be shown off - handed to your grandparents at a dinner table - unless you’re lucky enough to work in firmware. So when we talk about feeling burned out or frustrated with our jobs, it can be hard for people on the outside to understand - especially when we’ll talk endlessly and passionately about that very same job.

So I want you to imagine you’re solving a crossword puzzle.

Crossword Puzzle - Source https://commons.wikimedia.org/wiki/File:Crossword_puzzle.jpg

Solving Crosswords at Scale

You are part of a crossword-solving team, where you try and solve crosswords fast enough to win a prize from the publisher. There are a dozen of you - designated “clue solvers” - where you are given a clue from the puzzle to solve, then add it to the crossword. Aside from solvers, there are a trio of “word checkers” who’ll check your solution is in the official dictionary used by the publisher. Finally there are a pair of managers - one decides which clues should be given to which solver, and another who is responsible for making sure all the solutions fit together.

You receive the clue for 13 ACROSS - “A large mammal that is commonly found in wooded environments”. You know the word is 4 letters long, and the first letter of the word is a B because someone already solved that square earlier in the week. It takes you about five minutes to decide the answer is BEAR. The team process dictates that you need to have another solver review your solution, before you send it on to the checkers.

When your peer reviews your work, they immediately reply saying they can’t sign off on it because surely the answer is BIRD. They aren’t privy to the entire clue you’re trying to solve - all they know is that it’s a 4 letter animal starting with B, and they are unaware that one of the requirements is that it’s a mammal. They take 2 days to get back to you about confirming that a bird isn’t a mammal, during which you’ve spent most of your time double checking that a bird is, in fact, not a mammal. Eventually they accept BEAR could be a valid solution, whilst not being personally convinced for reasons they can’t fully articulate. It might just be because you annoyed them by not immediately accepting their BIRD answer.

Now you’ve had the solution reviewed, you take it over to the checkers. There’s already a stack of solutions from other solvers in their in-tray - annoyingly, including a word from the solver who just made you wait 2 days to get a review. You add yours to the pile, with the position marker 13 ACROSS. Somehow an irate message awaits you when you return to your desk, simply reading “BARE isn’t an animal, and normal people don’t get naked in the woods”. It takes half a day to untangle the miscommunication, where the checker team have a process of reading words out to one another in order to look them up in a dictionary faster. Finally, it’s approved, and you’re able to take it from the checkers to the managers overseeing the crossword.

On handing off the completed word, the lead solver questions why you didn’t use the word BOAR - they make a last minute executive decision to write that instead. You don’t have time to worry about this though, as the work organiser has given you your next clue to work on - 27 DOWN. You get back to your desk to look up the clue itself, only to receive a notification 30 minutes later that your work on 13 ACROSS doesn’t fit. This is because the word should start with a D not a B - the word that gave you that starting letter was also wrong. However you’re already reassigned to your new task, so the work on figuring out which four-letter forest mammal starts with a D is going to fall on someone else.

Turns out the crossword contest is won by two teenagers in kansas, who sit down together for a pleasant afternoon with a dictionary and rattle through the whole thing. They win the £100 prize, while your innovative puzzle-solving organisation folds 18 months later without winning a single contest.

The Misguided Desire to Simplify Problems

I feel like this approach to breaking down software development problems comes from treating the work like an assembly line. In a traditional assembly line the more you can break down the problem (starting from “build a car”), the more you can find micro-optimisations in the process, the more cars you’re going to get built. The problem in software is that as you extract individual problems away from the whole, it often becomes harder - not easier - to reason about them. Much like a crossword the surrounding problem of an application will inform the minute-to-minute decisions you make on how the specific piece of functionality you’re working on should be built. This is then compounded by introducing layers of review that aren’t centered around the functioning application itself - rather the written code in abstract, or some piece of specification in a ticketing system.

It would be easy to just paint this with a brush of “well, agile failed, we should go back to waterfall” - but nothing about agile demands the breaking down of problems at all. Seriously, go read the principles, I’ll wait. The closest demand it makes is “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” - but you can deliver working software all the time as you change it, even if you haven’t entirely solved the problem yet. To go back to the crossword analogy, there’s nothing stopping you from continually showing the puzzle as you fill in the words - and at a certain point, someone might decide you’ve solved “enough” of the puzzle for them to be happy.

This is where I get a bit radical in my suggestions of what did happen. Not-software-developers co-opted the language of agile (which to me, is a bottom-up movement for developers) while filling it with management processes and false notions of “scaling”. The problem is that as you try and “manage” your way to solving the problems, you’re essentially creating layers on layers of plan and administration - the very thing we’re supposed to be avoiding. Instead all you end up doing is obfuscating the true puzzle from the very people you’ve employed to solve it, while simultaneously removing their agency to get on and solve said puzzle.

But What Can I Do?

I’ll start with talking to anyone reading this who isn’t a software developer, and hasn’t closed the webpage already. I am begging you. Genuinely begging you. Start giving the whole problem to developers - either individually, or in very small groups of 2-3. More business value has been shipped faster (with less issues) when small, highly focused teams are given the problem to solve and a deadline to hit. It would be mad to pretend that this is a perfect way of working, and that all software developers are capable of it from the jump. But for a role that is supposed to be a skilled “subject matter expert”, businesses just can’t seem to help hiring a glut of developers and giving them tiny things to work on. In any other field tasks would be given in their totality - “Go win that contract”, “go put together that pitch deck”, “build out next year’s marketing strategy”. Yet it seems like larger organisations are happy to give developers the equivalent of “Can you make slide 17 of this powerpoint?”

For me, scaling a development department doesn’t mean you necessarily get things done faster, or better - but it allows you to make more bets. When individuals and small teams are trusted with an entire problem, suddenly you’re not having to fight upstream against conflicts between teams or situations where one micro-problem is trying to take priority over another. This is a little bit of a weaponisation of Conway’s Law - if you just let the teams own a part of the system, it’s engineering will naturally fit the existing communication structures of the organisation.

Now for the tough love moment for the developers reading. First, get your head the hell out of Jira - feel free to replace with the project management tool of your choice. The big mental shift for me was moving away from seeing Jira as my work - rather, it’s a way I can communicate about my work to the business. It’s the same reason I rally hard against tickets for refactoring or writing tests - that isn’t work you should be being told to do, that’s just your job! It’s akin to a woodworker waiting to be told to put all his tools away and sweep his benches, or a plumber not turning off the water unless the client asks him to. Sure, you could get away with not doing these things - and sometimes you might even need to - but just writing a note for someone else to deal with it makes you a bit of an arse.

Secondly, figure out what your business, your bosses and your customers actually care about - and then work on building that. Good software development involves drowning in the domain which your application serves, and growing an appreciation for the system and the people wanting it built. This isn’t about going totally rogue and doing whatever you feel like - instead, it’s about trying to move your problem solving for the business “up a level”. To call back to the crossword analogy - it’s like at least having a go at solving the clues that connect to your “main” clue, even if no one is explicitly telling you to do this. As a consequence you’ll be shifting your thinking from “how do I solve this clue” to “how do I solve this part of the crossword” - and the second is way more impactful. The truth is that the work that I’ve done out on a limb, trying to get ahead of the next problem, to solve the full business need, essentially never got rejected. This isn’t because I’m a genius, or some “10x-er” - it’s because I wanted to solve the problem of the person signing my paychecks, or the people paying that person, rather than getting bogged down into specific tasks assigned to me.

For further reading, give the fantastic essay “Programming Sucks” a go. It’s another take on this issue, focused on malaise around the actual job of coding itself, and if nothing else is dead funny. If you want something else written by me in the same vein as this, “Not My Job” which I wrote way back in 2020 remains relevant.