Why not? I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. Some "sexy" areas of programming (data mining, high scale apps) can be an enormous grind. Some CRUD business apps can be very rewarding. What matters is having a very good effort->reward loop. You can get that loop from building project management software. The specifics of the organization and the development process matter more than what you are actually building.
Indeed. The interesting programming problems are almost always independent of the business problem domain. I work for a company that writes HR applications. Very boring. The programming part, though, is very interesting.
Things like Moose, KiokuDB, and so on all came out of this work.
"I've come to believe that the actual field of programming matters much less to job satisfaction than the way it is done. .... The specifics of the organization and the development process matter more than what you are actually building."
This contradicts my personal experience.
I worked for a great organization (ThoughtWorks) which had a great development process (Extreme Programming with "lean" elements, with a lot of tailoring and flexibility, the team could do almost anything really) and I worked with great, awesomely talented people, but I got bored to death with the enterprise apps we were building (the domains were all incredibly boring to me, and I could switch off 90% of my brain and still deliver successful projects) and so I left.
Now I don't have an "organization" (I often work alone or with small groups of people assembled for a project and that too virtually), but my domains (AI/robotics/ Computer Vision/Planning software) are so much richer than what I used to work on, (and so is my toolkit - C, erlang,lisp etc vs java/ruby-on-rails) that I wouldn't exchange the "grind" bits of these projects for the "cool" bits in my old work.
I suggest that just as working in lisp maybe in general more pleasant than working in COBOL, (there will always be exceptional situations where COBOL is more pleasant, or the odd person who prefers working in COBOL), programmers would in general prefer some fields of programming to others.
You say,"What matters is having a very good effort->reward loop. You can get that loop from building project management software." .
I agree totally, but I'd also say that unless you are running your own startup making such software, this would be a rare experience.
In my experience the "reward" in enterprise software comes from understaning customers in depth and satisfying them. In a non startup enterprise coding effort, this is hard (but not impossible - see jrockway's example in his answer - I am just claiming this is more the exception not the rule) to do?
What Steve Blank calls "Customer Validation" remaining equal, maybe there are levels of "blub" in domains and/or projects too?
EDIT: This quote from PG expresses this idea much more clearly than I could
"
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The distinguishing feature of nasty little problems is that you don't learn anything from them. 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. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers."
from PG's "Great Hackers" essay.
PS: I don't claim to be a great hacker but I am probably a good one.
