Menu

Tag Archives: norbauer

There are a few things in this post by “Ryan Norbauer”:http://notrocketsurgery.com/articles/2008/02/26/mention-in-wired-piece-on-37signals (via 37signals) that bother me. One is this idea that “code is meant to be read by humans first and computers only secondarily”. I understand what he is getting at, but even though I respect new advances in productivity, we have to be very careful to keep our core priorities. There’s a word for when the balance shifts away from the user and more to us as programmers: selfishness.

Imagine two programs: one is ugly and hard to read, but it compiles and is bug-free; the other is beautiful and readable, and it also compiles and is bug-free. To the user they are identical. They both succeed.

Now take those two and give them both identical beauty and readability, but accidentally break one so that it either does not compile or runs so horribly buggy and slow that it is useless to everyone. Writing code for other programmers to read isn’t enough. You have to start with code that works before you get all fancy-pants.

This growing trend to raise beautiful code and programmer productivity above the performance or functionality of the final product is dangerous. The final product is what counts. Not how you build it, but what you’ve built: how it scales, how it performs, how it solves a particular problem.

And sure, there are many times when I write slow, lazy code that doesn’t work well. But that’s a compromise you make when you have to meet a deadline, or because you aren’t sure how to optimize yet, not because you start out by deprecating user experience. If you believe Ryan, it sounds like there is a whole “movement” of programmers who toss any potential performance achievements out the window before they even get started.

You can say that great products are complex, and so you need to focus attention on how the software is built and maintained. That is true. When I ported a large application from Carbon to Cocoa a few years ago I made the decision to do so because of future productivity.

You can say that happy programmers create high-quality products. That is also true. When I am feeling most productive I am usually enjoying myself because the work environment I’m in is encouraging.

But don’t put the practice of software development above the actual result, because to do so means you care more about writing code than solving problems.