Software Solutions

At my last place of employment, after being repeatedly approached about solving some troubling issues, I had an epiphany. Software is not about application development. It's not about web services. It's not about modelling, or simulation, or calculation. It's about problem solving. Application development solves the problems of making slow, tedious work quick and painless. In many cases, it enables us to do things we were not capable of before. Web services is similar, but the interface is in your browser, and the back end is on another machine. Modelling, simulation, and calculation are used to solve the very difficult problems of scientists, engineers, and accountants. Sometimes you just have a problem getting different software programs to talk to each other. And of course the solution is more software!

Great, so how does that help us? Let me start with the standard argument -- efficiency. When I was in high school and college, I ran a lot. I didn't win any races, but I'm confident that I was, at one point in my life, a better runner than most Americans will ever be. But did I make a big deal out of this on my resume? Did I write it in bold next to my degree? No! If I were applying for a cross-country scholarship, I would have made a big deal of it. But when I'm trying to impress the hiring manager, I don't talk about it at all. And that's because he probably does not care. He wants to be sure I have the skills and competence to fill the position he has. A world athlete is not going to solve his problem. But an aspiring hacker might.

Likewise, it often makes sense to NOT consider efficiency or at least consider it very little when writing software. And the reason is because fast software is not the problem you are trying to solve. You are enabling the audience of your work with new functionality. You are solving a scientific problem or an accounting problem. You are not comparing the speed or space requirements of your code to your friend's version. Perhaps the goal of your software is to make people feel good about themselves. Maybe your software is meant to make other software easier to use. Maybe it's a tool to make making software easier.

How else can this view of software be applied? I'm sure you've seen the long list of requirements for IT and software engineering positions. But when does it make sense to go looking for someone with all these skills? Suppose you own an organization with twenty Java experts and you have years worth of work invested in Java technologies. Would you suddenly switch to a better technology just because it's a little faster or claims easier development? I wouldn't. This is going to create new problems, not solve old ones. Suppose on the other hand that one employee did some work for you in an obscure language. The application has some basic functionality. Are you going to request that the next employee know this language? Are you going to spend 8 months looking for him? What if you're losing money all this time? Even if this particular language was the best tool available to do the job, I would probably not be willing to wait so long. The problem is you need work to be done now. The solution is to find someone who can do it, not someone who knows an obscure language. In many cases, almost any modern language will work. Almost any language can do what another can do. But some are better suited to specific tasks. And arguably, some are even superior in every way. But having the best coder in the best language isn't going to solve your problem. Your problem is you need the work done now.

I'm not trying to say you should never use the better technology. If it makes sense in the long run, you should make the switch. But you have to take everything into account. What are you trying to solve? Who is solving the problem? How much effort is already invested? Does it make sense to start over? Can we solve the problem with what we already have? How good does the solution need to be? Here is another example. Let's say your twenty Java developers need to add some new functionality to their one million line application. You have recently hired Guido Van Rossum himself, and he says the work could be done in three days in Python versus two months in Java. I wouldn't give up my million lines of code or twenty Java experts. But three days is a lot better than two months. MY solution would be to try to make the two work together. I might even make minor changes to the existing architecture if it allowed different languages to integrate easily. There may be future benefits of this as well. It all depends on the situation. You just have to stop and think it through for a bit. How are we going to solve this issue?

The last thing I want to mention is programmer resistance to new languages. Often programmers coming from a C background tend to resist higher level languages like Python. After all, the first thing that comes to mind when you hear of such a thing is "It must be a thousand times slower!" And sometimes it may be. The reverse is also true. Someone who has only ever worked with Java or Python might wonder why in the world you would want to deal with things like memory management. But there are reasons why you would want to use any of these languages. After you've used them all for different tasks, you begin to understand why. You just have to figure out which one makes the most sense for the problem at hand.