It’s All About Balance
A few things have happened to me within the past 24 hours or so which have caused me to reflect on the art of balance.
Yes. That’s right. Art.
Balance is a skill. It a branch of science. It’s a calculation. It’s an assertation. These are all very deterministic adjectives. Very analytical. Then why call it an art? Because whatever your natural affinity for balance, it takes a certain amount of practice and experience to achieve it gracefully.
I’m not talking about physical balance, in the sense of Tai Chi or ice skating. I’m talking about balance in software development.
Last night I reached a very minor milestone in a personal project of mine (a high-speed data storage system) and I came to a point where I needed to stop and think to myself: How do I proceed from here? My first and primary goal with this system is speed. Raw horsepower. Later, once I feel comfortable with it, I’ll worry about things like high-availability and all the garbage that comes with it, but my first objective is laser focused on insane single-(server-)node performance. It’s coded in C/C++. Do I use direct system calls and handle each and every little operation where necessary? Do I manipulate APIs in their intended format? Or do I use nice OO class wrappers, and eat a few cycles of overhead due to object creation/destruction and method calls that do nothing more than call their lower-level counterparts?
My answer: Use the wrappers.
This afternoon I was chatting with a new coworker of mine (project information and shameless plugs coming soon!) about a generalized manifestation of the same predicament. To abstract, or not to abstract? When you don’t, you save yourself some processing cycles during execution, but maintenance can be a nightmare. When you do abstract, the job is easier (overall) and saves you time coding. I also like abstraction because it allows you to focus on what you want to do, rather than the nuts and bolts of doing it. The whole “forest and the trees” analogy in disguise.
My answer: Abstract.
And just earlier this evening I was reading a post by Jeff Atwood where he argues that programmers need not also be a hard-core mathletes to effectively do their job. While I like to agree with the fact that every developer on the face of the planet doesn’t have to have a mastery of vector calculus or be able to multiply three five digit decimal numbers in hex, I don’t particularly like the dismissal of the subject in general as applicable to our field. I digress.
Jeff’s Answer: Learn what you need to, when (and if) you need to.
Why code abstractly when all it does is take up CPU time? Why don’t you need to spend 4 years studying mathematics to program a simple socket server? The answer: balance.
There are two kinds of people (wayyyy broad overgeneralization coming up here – prepare yourself) on the Internet. Those who are looking for finished goods and services to consume, and those who are looking for good ideas and proofs of concept to produce new goods and services. If you’re in the latter group, the code itself won’t matter a great deal (yet). If you’re in the former, then your time is probably worth a lot more than not using that graphics library in the raw. One instance where you can probably get by throwing hardware at the issue (again, I agree with the fundamental premise of his post, but I think Jeff takes it too far).
There is a delicate balance to be struck between the intensity of recoding the POSIX threads library for your application, and using the one right in front of you. Between pure MVC design, and just tweaking this or that for it to work. Between using regular expressions, and standard string functions. Between ensuring your loops are well-formed and variables are all passed by constant reference where possible, and not. Between measuring which is faster for copying strings in C, strcpy() or memcpy(), or not caring and moving on.
You might notice, that those arguments get more and more “reasonable” as the list goes on. There’s always a balance point. Where Google has the infrastructure, time, money, programmer-hours, technical fortitude, and probably reason, to write their own thread library, you don’t. You don’t (probably). But do you have (and should you spend) resources on deciding whether or not to use PCRE rather than grunting through the task with standard string methods? It depends. You’ve got to weigh your time (not just inital development, but also maintenance and upgrade time) against the efficiency gain or hit (depending on how important this is in your application). It’s all about balance because you want your code to be efficient, but Jeff’s right, your time is more valuable than your hardware.
