The Tao of Coding

by Ed on November 12, 2005

The sword maker… continuously polishing, honing. So must your coding be if you are to be successful. Sure you can throw stuff together and it might work, but what about later, when you have to change something. Will you remember what you were trying to do with some piece of code? Will you even be able to read it? What happens when a major revision is needed?

Here are various principles of the Tao:

  1. Take a little extra time to do things right.
  2. If you add code to a function, it should never look like an afterthought.
  3. Performance is a feature. It must be there from the start.
  4. Keep the future in mind. Add foundations in one revision to help bridge to the next.
  5. Unify and Simplify. Pick models that can be used everywhere for multiple things.
  6. The foundation must be solid. Things like your string class are critical.
  7. Fixes to problems should be well understood.
  8. If you encounter code that is lackluster, improve it. Polish is the way towards improvement (of the code, and your skills).
If you do not follow this path, the results will be a giant, lethargic mess. I promise you. Hacks upon hacks. The ‘just get it done’ mentality leads to whack-a-mole problem solving where your code is fragile and any attempt to change something leads to another problem. It also means that you typically don’t have any clear architecture, and later on, major changes will be very slow going, if even possible. Everything will break in spectacular ways.

This manner of thinking also leads to poor performance. Performance is not a last minute “ok, let’s speed it up now” problem. You need to think about how things will perform as you are designing things. If you wait until the end, and it’s discovered the only way to make stuff faster is to rearchitect, you’re schedule is in trouble. What often happens is that it ships with bad performance. Noone wants something that’s slow, no matter how cool. It simply has to perform. This performance mantra of “performance is a feature” was drilled into us at Apple, and I have to say they were right. It’s just a really good attitude to have.

The general philosophy of the Tao is to simply always try to ask yourself, “is this the best way to do this?” and not stop until it is. I realize there are schedule impediments to always doing your absolute best, but you have to strive for this at all times. While working on the HIToolbox in Carbon at Apple, I always had this vision of what the Toolbox should be like. When I had arrived, it was pretty messed up. Half of it was still in 68K assembler, and we had open data structures which made it hard to modify the Toolbox and move forward with it. In Carbon we got to clean all of that up (actually, it started earlier than that… back in 8.5 when we did a PowerPC native Toolbox, but Carbon was the time when our datastructures went opaque). This allows us to keep polishing the internals of the Toolbox in ways that were non-obvious to the outside observer. When I left, we had a very cleanly written, self-consistent Toolbox. Almost everything had been rewritten in some form or another and was designed to work together, using simple core concepts throughout. We could write new views in no time flat. Dare I say we could write new controls, etc. just as fast as they could in Cocoa.

The above brings up an interesting point: you need to know where you are headed. What do you want the code to be like? Even if you cannot get there in one release cycle, keep that picture in your mind and keep revising the code to fit that model. If you have a little extra time, rework some internals to allow you to bridge the gap between now and then. Point two to take away from the above is to find core concepts and use them everywhere. In Carbon, we created Carbon Events as the messaging model, HIObject as the general object type (complete with subclassing by external developers), and HIView as the one view system. Before Carbon Events, there were various ways to get messages back and forth, or to write defprocs (bits of code to drive windows, menus, and controls). Before HIObject, it was impossible to extend the standard controls and internally we had 3 or 4 versions of almost the same code for menus, windows, and controls. Before HIView, the defprocs model for the UI elements were all different. At the end, we had one message model, one data model, and one view model. Much easier to learn and wrap your head around.

I mention a point about understanding fixes to problems. This is actually very important. It’s not enough to simply say “this fixes the problem”. You have to always understand why it fixes the problem. Strive to understand what exactly caused the issue you are seeing. Sometimes, you might even want to write it down. Not only do you learn a lot about the internals of your code, you might uncover larger issues that you’ll be glad you found. Writing things down might be useful later if you encounter something similar (or Lords of Cobol forbid, the same bug).

Follow the Tao and it will pay off. Time spent improving your code is time well spent. I already mentioned how at the end of my tenure at Apple, the Toolbox was in amazing shape. I’m very proud of what we pulled off, and it became a breeze to maintain the code and develop new features and controls. This is also where I’ve been taking the Konfabulator sources. In some future entry, I’ll discuss how the Tao helped out Konfabulator as well. Until then, stay on the path!

{ 0 comments… add one now }

Leave a Comment

Next post: