There are good problems and bad problems when developing software.
A good problem is designing an elegant caching mechanism for your configuration variables, or determining how to architect your service oriented architecture so it doesn’t look like the New York subway system.
A bad problem is figuring out how to re-architect your code to work with a partner whose API goes down twice a day, spending three hours trying to get your code into source control, or filling out ten minutes of paperwork for a five minute code change.
Paul Graham makes mention of this in Taste for Makers:
“Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.”
And in Great Hackers:
“One of the worst kinds of projects is writing an interface to a piece of software that’s full of bugs…you don’t learn anything from [doing this]. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random…Working on nasty little problems makes you stupid.”
Bad problems are not interesting, not fun, and they teach you nothing. They create frustration and, given enough of them, will eventually cause burnout.
I’ve seen a string of bad problems last for months, and cause developer after developer to leave a company in search of more interesting work. Bad problems wreak havoc on your ability to meet Rob’s Criteria for Keeping Your Developers Happy.
Look at any large financial institution, government agency, and [insert name of large organization that considers developers to be a cog in their wheel here]. I’ve worked at a few of these companies, and often hear developers who are out of work joking: “If things get bad enough I could always go work for Company X.” Ouch…tell me that doesn’t hurt your ability to find good people.
On the flip side, look at Google, Fog Creek Software, and SourceGear. I’ve never worked at these companies, but evidence is strong that good problems are at the forefront of their agendas. And by some shocking coincidence they get a bazillion resumes for every open position.
A steady stream of good problems is the foundation for keeping your developers happy. Minimizing bad problems and maximizing good problems should be every development manager’s #1 goal.