The posts in this series are derived from a series of talks I gave to other software engineers (you can watch one of them here) just entering the industry or at the ‘lead developer’ level. It has been a challenging presentation to put together, and each time I do it, I wish I had done things differently.
These blog posts are an attempt to do just that.
In these posts, I’m hoping to deal with the topic of ‘boring’ projects. I’ll look at what boring means (to me at least) and how the negative stigma of ‘boring’ projects is undeserved in many ways.
I’ll be upfront; I don’t find what most people consider ‘boring’ projects very dull; I’m hoping to convince you of the same.
I’ll talk about my experience hiring, managing and delivering with software teams working on ‘boring’ projects. I’ll also stop putting ‘boring’ in scare quotes…maybe.
Hopefully, you find the boring topic interesting enough to read through and will come to understand why I feel surface-level ‘boring’ projects aren’t necessarily just that.
I might even convince you to find your own boring project for your next role.
Firstly what do I mean by boring?
Well, think of the CRUD database-driven back-office software doing all the menial heavy lifting of dull data. For example – an appointment scheduling system for hairdressers; a specialised calendar app for compliance officers to inspect workplace safety regulations; an online timesheet management system.
There’s a hell of a lot of boring software that gets developed. When we see these projects, we think:
- It isn’t flashy
- It isn’t going to change the world
- It won’t keep us ahead of the curve
- It won’t look glorious on our CV
These applications are essentially ‘upgraded spreadsheets’ and are often entirely unsexy.
Such software systems are legacy cash-cows, ripe for disruption but often not seeing any for decades. They also tend to be risk-averse – like a massive ship in the ocean, only able to turn small amounts at a time and rarely changing direction.
I am sure there’s plenty of people who do find these systems ‘unboring’ – and there will be lots of ways they could be ‘unboring’…but they often aren’t.
I don’t want to say ‘interesting’ as that isn’t quite right, because all software has some interesting elements. I think ‘unboring’ projects usually have a technological or moral foundation that is both appropriate and has a specific place in the hype cycle:
So, assuming the technology applied to a project’s core is appropriate for the job and that the technology lies before the ‘Trough of Disillusionment‘, then typically these projects are unboring.
These projects tend to solve novel or important issues requiring new technology and are inherently attractive to programmers.
They’re cool.
Everyone loves working on cool stuff.
‘Boring’ projects tend to deal with known problems and apply technologies that have long passed the ‘Plateau of Productivity‘ and are now staples of our development toolkit.
And so it is, the technologies that make projects attractive today will become tomorrow’s standard tools should they survive. Similarly, the cutting-edge, innovative, and exciting companies and projects of today will soon become the cash-cow, risk-averse, legacy boring projects of tomorrow – should they build a moat.
Boring projects, as with most things, are a continuum. As engineers, we know that things like building ‘brochure’ websites in WordPress usually lack the draw of an AI-driven start-up drawing exciting conclusions and building new models of the world.
They just aren’t as sexy.
With this ‘boring vs unboring’ disparity, we must be wary of impostors; of those trying to capitalise on the developers’ desire to work on unboring projects.
They litter the jobs market with role descriptions highlighting the problem. Every job seems to shout “HEY! We work with the latest and greatest framework! Come work for us!”.
In a market where the supply of technical skill is below demand, who can blame people marketing to attract the right candidates? After all, the ‘right’ candidates are looking for unboring things to work on, aren’t they?
The trouble is that in many cases, it’s misleading marketing, or there’s an inappropriate use of new technologies in order to attract talent.
Here’s what I feel boring projects look like:
- They use technologies that have long since traversed the hype curve to the end; The novelty has worn off.
- Their problems are niche, uninteresting or serve a purely commercial purpose.
- They are likely to be legacy, risk-averse and possibly in ‘maintenance mode.’
- They may be a cash-cow, operate in an underserved market, or a market whose incumbent players are entrenched.
- They probably don’t attract the best and brightest minds.
And here’s what I feel an unboring project looks like:
- They are seemingly solving problems that resonate with people (global warming, better consumer capital allocation, empowerment, democracy, equality, etc.)
- They are appropriately and relevantly using technologies that are new or early in the hype curve to solve problems.
- They are disruptive, revolutionary or innovative.
When framed like this, it seems like boring projects are ripe for disruption!
I often see these projects and think they’d make an ideal basis for a startup. There’s plenty of blog posts and books that deal with this topic so I won’t go into it.
What I will point out is that boring projects have many, many opportunities for the individual programmer to grow their skillset, income and prospects quickly.
If you learn to love boring, you’ll exploit an underserved niche as a programmer.
If you can love boring enough to make it unboring, you’ll do more than just earn more and gain a competitive advantage in the jobs market…
In the next post, I’ll talk about the reasons projects get boring and the strong scaffolding that holds them in place.
Only by understanding the context and history of boring projects will we start to see why they are boring and the interests we need to serve when dealing with them.