Rockford Lhotka has a nice rant here about the topic of software and software developers. I have to say that Rocky makes a lot of good points. I don't agree with all of them, but the basic idea is very sound.

Besides, I have to admit I'm one of those that sometimes I'd rather be solving our own problems rather than those of the users; it's hard to get out of that mentality some times (and I think most of us have found ourselves in that position at one time or another). A very interesting question then is why we fall into this pattern again and again.

I think there are several things that might cause this, and it might be particularly true for those of us that work (or have worked) with multiple clients:

• Sameness: Let's face it. A lot of applications users ask us to build are basically the same. Your basic business data-entry application is essentially the same (at least from a high-level point of view). Boring? Hell yes. But then again, one has to wonder (as Rocky does) just how is it that we still haven't perfected a way to build them.


• Lack of business value: Many developers care more about their own stuff than about the business value they deliver to the application's users and stakeholders. That's a problem. But many of us do care a lot about this, and yet, find ourselves in bad places where the perceived value is just completely false. How many of you have realized that the application the user asks you to build is pretty much useless (really won't solve the user needs) or that its value is based on a false premise (thus making the value completely meaningless). You've probably told the user about this only to be ignored. Demoralizing? you betcha. Building the wrong things for the wrong reasons can easily make you care more about your own technical problems than about the real issues.

Overall, I think Rocky does nail the core issue: We software developers are usually supposed to solve other people's problems, that are outside of our core knowledge domain (building software, computers, whatever you want to call it). This is significant for business applications the most because the core problem the user wants solved is the business problem, not the application development problem. This is a significant dilemma I've thought about a number of times, and I'm not sure how many other professions out there have this as a key part of what they are really supposed to do. Every professional solves someone else's problems (a civil engineer builds a bridge to solve someone's transportation problem, for example), but the problems themselves are usually not that orthogonal, I think.

Update: Thinking about this a bit more, I can actually see some specific examples that do share this particularity of software development. For example, there are architecture and civil engineering especializations on, say, building airports and airport infrastructure, which definitely is very specific domain knowledge. Should we have something similar in software development?