One Eye Open

In the land of the blind, the one-eyed man is king.
[In regione caecorum rex est luscus.]

Desiderius Erasmus, Adagia (III, IV, 96)
Dutch author, philosopher, & scholar (1466 - 1536)

When you first get into building software it is exciting. There is a definite thrill in gaining a new found ability to create things, watch them run, and see people start to use them. I’ve always felt that it was this ‘high’ that keeps me coming back -- again and again -- even though software development is so plagued by other annoyances.

But some days it can feel  like I am dragging around a big cart behind me, filled with people kicking and screaming, while beating me on the back of the head as I am trying to focus on how to get us out of the hole and onto our destination as fast as possible. It can be a thankless job some days (when they’re not heaping false praise upon you for lesser accomplishments), but that is another story, for another day.

When you first start programming, of course you focus in on the code. It is on the small problems, which are fun and interesting. How do I manipulate this string? How to I can I call this library? How do I make this screen pretty? How do I store this data? And it is too easy in the midst of all of this to see the ‘code’ as the most important thing.

In my early years, I felt that all I needed was time. And with time I could get code, and with code I could solve any user’s problem.

But age and experience gradually creep up, and after many many experiences of seeing that the code itself didn’t save the ship, or make the user’s happy, or contribute to a career, you start to see software from a completely different perspective. It’s at that point that you awaken one day to the larger context that is swirling above the code.

There is this sudden rush as your other eye opens. You come to realize that the best algorithms, coded in the best ways, and tested with the best results, still won’t allow you to win if winning isn’t possible. You realize that any and all technologies -- no matter how slick or smooth -- are fraught with an endless series of hastily coded landmines just sitting there, waiting for you to take a fatal step.  You come to realize that a poorly coded system that makes itself easy for the users has way more value then something super-complicated with buckets of functionality but is entirely cryptic, badly organized or untrustworthy. You come to understand that while the implementation is important, it’s not the ‘thing’; not the show, and not necessarily going to mean the difference between success and failure.

But most of all, you wake up to the fact that the ‘code’ itself is just a part of the puzzle, and that the algorithms, while fun to solve are the small problems, floating is a sea of large and massive ones.  

I’ve watched more programmers than I care to admit retreat into the small problems and corner-cases to avoid the big ones. I’ve watched them throw all of their coding weight into extended blitzes hoping to save an already dead project. I’ve watched them burn through rolls of virtual duct tape in the faint hope that at some point they’ll get to the other side. I’ve watched them ignore the users, blame the management and generally try every trick in the book to avoid having to deal with the part of software development that they don’t like, or are afraid of. And I’ve never seen it work.

Programming is a part of software development. It is an important part and for many people it is the part that they are good at, enjoy and should focus on. But it is in no way the part that is going to carry the day. A well-built project is no less doomed than a poor one. The quality of code may become an issue at some point, particularly when it means that any new extensions are impossible to accomplish because the system has acquired way too much technical debt, but that type of premature death is just one of the many ways that our work dies, there are so many other hurdles that have to be jumped.

As is often the case, the larger issues have to be handled before the smaller ones can be successful. Architecture, design, process and consistency are necessary to keep the project sane. Empathy, politics, marketing and an understanding of the target market are necessary to make the software useful. Testing, packaging, installation and support are necessary to keep up the momentum and avoid getting bogged down by sloppy patches and dangerous work-arounds. And elegance, readability, simplicity and encapsulation are necessary to avoid painting one’s self into a corner at the later stages.  

What algorithm you choose, and whether or not the you’ve applied a lot or a little micro-optimizations? These help, but at the end of the day they are just icing on the cake, or as is the case in many development shops, just icing on the floor.