Some problems are not nails

Solve a problem in the furniture industry and the worry is that you end up as nothing more than an innovative carpenter.

Ingvar Kamprad founded Ikea to solve a problem in the furniture industry and was at one point the eleventh richest person alive and he did it without writing a line of code. That isn’t a trick answer or a on purpose awkward counterexample. It’s the ordinary case. If you find a solution to a pain that a large number of people are actually suffering then you can make an enormous impact and quite possibly a great deal of money and the medium you happen to use to deliver it’s close to beside the point.

It doesn’t have to be code and it definitely doesn’t have to be good code, which is the part that tends to annoy people who take some pride in writing it well. Very often the whole thing can be done with no code in it anywhere and the fact that this feels faintly insulting to people who write software for a living is worth sitting with rather than arguing against.

Look at what actually kills things instead. You can ship the best functionality anybody has built in that space and fail totally because nobody hears about it or because the people who hear about it can’t work out what it does or because they understand it perfectly well and don’t care or because they care but can’t see how it helps them or because they can see exactly how it helps them and can’t afford it. Every one of those is fatal on its own and none of them is a technical problem. You don’t fix any of them by making the software better.

This is why the framing of the original worry is upside down. The concern is that solving a non-software problem wastes your technical ability, when the thing that most often goes to waste is technical ability applied to a problem where the hard part was never technical. The carpenter comparison is meant to sting and it should probably land the other way round, because the carpenter at least knows what business they’re in.

I like writing code and I solve a lot of problems with it. It’s also obvious after enough years that there are problems code isn’t suited to and that a decent proportion of what looks like a software problem at the start turns out to be a distribution problem or a pricing problem or a problem where the customer already has a workaround they’re perfectly happy with. Those don’t become software problems because a software person picked them up.

Code is a hammer. It’s an excellent hammer and there’s a lot of satisfaction in swinging it well and the reason so much effort gets spent on things that were never going to work is that the people holding it are very good at using it and would rather not find out that this particular problem isn’t a nail.

The test is easy enough to run on yourself. Take whatever you’re building and ask what has to be true for it to work, then sort that list into the parts that need code and the parts that don’t. If the code half is short and the rest of the list is long, you’re not doing a software project. You’re doing a business with some software in it, and the skill that decides how it goes is one you may not have been practising.

That isn’t a reason to stop. It’s a reason to stop treating the code as the hard bit.