As I work in this industry on a daily basis, I come into contact with more and more people who write software in one fashion or another. Some are hobbyists, some are small business owners trying to be more productive, and some are professionals who get paid to write code and develop software. I am always surprised at the number of professionals who, by word or deed, express that they are not concerned with business problems, only with technology problems. I’ve worked with people who will gladly stay up all night long trying to figure out why IIS isn’t delegating security credentials from one machine to another, but are absolutely uninterested in figuring out whether or why the business needs a web application in the first place. I am an artiste, this particular subset of software professionals seems to say.
If you’ve ever encountered one of these types, you know it. And although these folks are in the minority within our industry, they are visible enough to give us all a bad rap – one bad apple and all that. So for the benefit of everyone who creates software in one way or another, let me say this:
You are not an artiste. You are not even in the software business. You are in the problem-solving business. More to the point, you are in the business-problem-solving business. The technology problems you solve should always be in the context of solving a business problem. If the solution to a particular business problem offers less benefit than the effort required to solve it, you should be working to solve a different problem.
There, I said it. A lot of people will not like hearing this. Some will disagree vehemently. And that is OK. But the truth remains – it is the job of the software developer to solve problems. Technology does not exist in a vacuum. A well-written, elegant, extensible, scalable, n-tier application has no intrinsic value. It is only when such an application solves a business problem that it creates value. That’s why we call them applications – unless the software is doing something, it’s just bits and bytes on a disk someplace. As a profession, we need to get hip to being able to recognize and understand business problems.
In fact, sometimes technology is not the solution to a given problem at all. Just the other day a client asked me to re-write a portion of the home-grown application he uses to run his business. I declined, pointing out that a simple change in process in his back office would solve the problem they were having. A pure technologist would see this as a technology problem, when in fact it was a very simple business problem. Now, I could have re-written that module and made a decent amount of money doing it. And sure, that would have solved his business problem just as well as the process change would have. But there was no need for that particular expenditure of time and money to be made.
It is important to avoid the old “when all you have is a hammer everything looks like a nail” type of thinking. And personally, I think a lot of us need to be reminded of this fact. Admittedly, my point of view is colored by the fact that I didn’t study computer science in college – I studied management. But the most successful developers I’ve met are the ones who, regardless of training, are able to understand that technology supports the business need, not the other way around.
Now, lest anyone think I’m belittling programmers or software developers, I am not – remember, I make my living in this industry, too. I stated earlier that I am talking about a relatively small but visible subset of the profession. As developers and programmers, we possess specialized skills that are frequently vital to the effective operations of businesses big and small, just like the specialized skills possessed by accountants, craftsmen, managers, and salesmen. It is all part of the great mosaic that makes up a business. I believe we matter in the workplace, and we matter a lot – so long as we remember why we matter. We matter because we solve business problems. Those of us who are content to flip bits and bytes with no desire to understand “why” in a business sense, or with no desire to make the bits and bytes line up with business value, are at the very least wasting the valuable material between their ears.
To have a desire to code – and only code – for a living is OK. But to wear blinders while doing said coding for a living is not – that effectively reduces you to the role of an assembly line worker who adds his piece to widget as it rolls by on the conveyor belt, never to see or understand the completed product. And I think that good coders and good developers are much, much more valuable than that and have much, much more to offer.
To those who shy away from business issues, I say: come out of your shell. Nobody is asking you to be a business analyst, but at the very least, always seek out the business context of what you are working on. Always. At the very least, always seek to be better informed and truly understand why you are building what you are building. Always. It is better for your clients. It is better for your career. It is better for the image of the profession. And it is better for the economy at large.