Reflections on software

When faced with a new programming challenge, it can usually be approached from one of two ways: the front end or the back end. Each has its merits, and completely focusing on one or the other is a recipe for disaster. But, I think that most programmers tend to be a little "backend heavy". I'd almost go so far as to say that it's difficult to call yourself a programmer without being biased this way. After all, programmers enjoy solving complex problems by creating new powerful abstractions. If not, you'd be a little nuts to go through all the frustrations of programming without enjoying watching something work.

What I find surprising is that if a problem is too simple, it's the programmers themselves are the ones that create more complexity. I find myself doing this all the time. "Well what if the user wanted to do foo and not bar. Instead of hard coding this action, I can add a new <insert cool pattern/framework/abstraction here> and the application will then support any action. Then we can make a user preference and new configuration management system that users can tailor to their needs". This cascades of course, and before you know it, you've created a new framework. It's just so easy to get lost in it, that programmers sometimes forget to ask the obvious question: "hold on a sec, why are we doing this again? Let's just cross that bridge when we get to it".

Focusing completely on the front end can be just as problematic though. Security holes, performance bottlenecks, and general lack of flexibility can hold you back too, perhaps even more so. Any one of these issues can be devastating. Then it'll leave you wishing you had spent just a whee bit more on prevention, instead of having to pay so much for the cure.

Right about now it sounds like my point is that everybody should just do things right from the beginning, without wasting time building anything unnecessary. But realistically, I think the most important thing is to "use your brain". The applications that programmers build are supposed to be helping users in some way. Refactoring is supposed to help programmers maintain their code. Writing tests is supposed to help maintain confidence in the code base. User testing is supposed to help inform usability improvements to the application itself. If something isn't working like it should, maybe it needs to change, or be rethought. It's always healthy to take a step back and review how things are going. I think Einstein said it best:

Everything should be made as simple as possible, but not one bit simpler.

For any given problem, there are lots of tools out there to help us solve it. The programming world is no different. In fact, programmers usually have very strong opinions on the tools that they use. Some will even outright refuse to work with a particular tool that they don't like. And in some cases, this is for good reason. After all, you wouldn't build a rocket armed only with a hammer would you? (Iron man doesn't count) Well in the software world, chances are that you wouldn't want to build a web app using assembly, or a command line tool with a gui builder.

But in the real world, or at least my world outside of clear cut examples, the answer is not always obvious. There are many tools that would do the job, and they would all do it well. And what's more is that it's difficult to predict the future of a particular project, so how do we know that the tools we pick today are suited for future needs? (Of course with python, the answer is simple: from __future__ import tools)

There are more web frameworks than I can count to, and we still can't agree on which text editor to use. (I myself use nothing but ed, because it's hardcore and it's what picks up chicks in a bar.)

Fitness experts also have these kinds of problems. If I want to build more x muscle, or get better at y, how should I work out? What should I eat? These are not always easy questions to answer, and what's more, is that if you ask 5 experts you'll probably get 5 different answers. But, I ran across one interesting response:

Everything works, but nothing works all the time.

I think this holds true for programmers too. I for one find myself constantly comparing different characteristics of similar tools, trying to come up with which one is "the best". However, when coming up with which is better in my mind, I usually only consider my particular short term needs, so my conclusions tend to be biased. Then when faced with similar problems in the future, I go with what I know. But of course, this time it might not be the right tool for the job. I could try to be hitting everything with my new hammer as if it were a nail.

Which brings us to another quote:

The best workout is the one you're not doing.

New frameworks, new languages, and new concepts are what expand our minds the most. Change the tools you use every now and then. You'll be glad you did.