The Two Rules of Great Programming

2008.11.07   prev     next

As for what this all means, I’m still trying to figure that out. I abandoned seven long-held principles about business and software engineering, and nothing terrible happened. Have I been too cautious in the past? —Joel Spolsky

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience. —John Gruber

I’M about to save you a lot of money on books about programming theory. There are really just two rules of good programming:

1. Bugs are bad — Your app should work correctly as designed and/or as its end-users expect it to.
2. Occam’s Razor — Simpler solutions are better, provided they still accomplish the same result. So simpler code is better if it does the same thing as more complex code. And a simpler, more intuitive user interface is better than a more complex one that enables the user to do the same things.

That’s it! Those are the only real rules to good programming. That, and of course being smart enough to know what algorithms you need and how to code them.

You can’t fill a thick book with rules about what good programming is all about unless you make up a whole lot more than the quarter-of-a-page taken up by the above rules. And all that made-up filler is utterly arbitrary. It’s what the author(s) of the book prefer to do. Or maybe not even that — it might be merely what the author(s) would like you to do if they were your boss, even if they don’t consistently practice it themselves. It might be stuff that sounds really good in a book, until you actually try to do it and discover it sucks. And of course a whole lot of it is vacuous, fortune-cookie fluff, in the same vein as “buy low, sell high,” or “spend more time exhaustively looking into everything” — or just “do more.” It sounds like good advice, but it really doesn’t help you at all.

And when they conflict, which authors do you follow? Try to figure out who’s right in the following (fictional) conversation:

A: And then the webpage builds a temporary PDF file in this folder on the server, and serves it up to the user. Problem solved!

B: What happens to those PDFs? Will they just accumulate on the server?

A: No, every time it creates a new PDF, it first deletes existing PDFs that are older than 24 hours.

B: Oh. But what if nobody uses the app for days? How will the PDFs older than 24 hours get deleted?

A: They won’t — but if no one is using the app, then PDFs aren’t accumulating.

B: That sounds flaky. I think we need a service that checks every night and deletes these PDFs if they’re older than 24 hours.

A: But what if that service goes down and nobody knows it? Then the PDFs will just accumulate. And do we really want yet another service to maintain?

B: Well, we can’t depend on future user activity to delete temporary files. That’s just a bad idea.

You could write a proper-programming book and in it argue for either A or B — whichever you like better — and present it as if it’s obviously the correct position. Here’s a choice example from a certain programming theory book of which I once was required to read large portions:

What you’re trying to do [by appointing a project librarian, setting up meetings and forums, and frequently reviewing each other’s code] is foster an environment where it’s easier to find and reuse existing stuff than to write it yourself. If it isn’t easy, people won’t do it. And if you fail to reuse, you risk duplicating knowledge.

Bad news, guys: If it isn’t easy to appoint a project librarian, set up meetings and forums, and frequently review other developers’ code, people won’t do that. As I pointed out a little while ago, authors of programming books want you to think that your job is to make things easier for other programmers, because that’s what they (the authors) do. But if you really want to make something that people go “wow” over, then you’re not trying to make things easier for other programmers; you’re trying to make things easier (and better) for the end-users, who typically aren’t programmers — and even when they are, they would probably rather your app kicked ass from an end-user perspective than be easy for them to goof around with in the sourcecode.

My biggest and most appreciated project to date is SWTSG. When I think about how I would have to have written that app to satisfy almost any “good programming” book’s authors, I can only recoil in horror. Among many other things, I would have to have:

• developed six OS-compatible fonts, then figured out a way to make the required glyph distortions work with fonts in that format (if possible at all)
• figured out a way to include those six new fonts with my app and make them install on the user’s computer
• supported Unicode from the get-go, instead of modifying the app later to support it
• written everything as OO (ObjC) classes, regardless of the effect on speed and/or portability
• regularly submitted my unfinished code to other developers in internet forums for their review and criticism, which would have made the whole thing into an exasperating exercise in dealing with other persons’ attempts to project themselves as teachers and me as student, and which would have turned the whole project into a group effort with unpredictable outcome
• scoured the internet and other “official” code sources for pre-existing libraries which I could link into my project and use, instead of “reinventing the wheel,” then found a way to ensure that my project can discover and draw-in any updates to those libraries
• break down all the necessary complexity of the app into many, small, interdependent pieces, any one of which will not intimidate other developers into washing their hands of trying to understand it, and instead authoritatively declaring that my code is an incomprehensible mess
• riddled the entire sourcecode with lines that are blank except for a single brace character — a practice which almost everybody thinks an improvement in readability, for no reason that I have been able to discover
• completely forgone the “wow” factor that results when users see a fantastic finished product that they had no idea was even under development — maybe, if I was very lucky, a limited version of the app (perhaps rendering the crawl only) would be just coming out today, after years of work and general internet awareness that the project was underway. It would have been a big disappointment, and no one would say “wow.”

Grab a couple “proper programming” tomes and you can probably expand the above list to many times its current size. Suffice it to say that the project would have been utterly ruined if I had tried to satisfy these authors’ ideas of how software should be developed.

Sometimes you just have to go with your gut, and know that if you’re so far out there that society is actually threatened by your activity, then society certainly has the power to stop you. If it doesn’t stop you, then the proof of the pudding will be in the eating — and only afterwards can the recipe be subjected to an anal exam.

See also: Faster Is Better

Update 2009.09.24 — Don’t miss Joel Spolsky’s “The Duct Tape Programmer.”

prev     next