Sunday, 13 November, 2005

Thoughts on programming while building a fence

I spent part of yesterday afternoon and a large part of today replacing about 100 feet of fence.  The old wire had been there for over 25 years.  It was rusted, broken in places, sagging , and generally in poor repair.  Charlie figured out how to wiggle under the fence last week and I was getting tired of having to supervise him every time I let him out in the back yard.

Actually putting up the new fence takes relatively little time.  I spent more time removing the old wire (including removing a few small trees that had grown up through the fence) and moving a large pile of rocks in the corner.  Installing new posts, stretching the new wire, and attaching it to the posts only took a couple of hours.  Even that's not too demanding:  stretch the wire and go along with hammer and staples.

Except at the edges.  You see, in order to do it right you need a sturdy post and the fencing has to be attached to it securely.  The best way to attach to the post is to wrap the wire around it and then twist the end of the wire back around itself in a particular manner.  Doing so will prevent the wire from slipping when you begin stretching.  Stapling the wire to the post doesn't work, as even a moderate amount of tension will pull the wire right through the staple.  Securing the wire to the post is tedious and time consuming work, but it's the most important part of installing a fence.

It was while I was wrapping and twisting that I realized something:  like programming, the hard part of putting up a fence is the edges.  The end post is the fence's interface to the world.  The other posts are just internal support.  Get the end post right and everything else just works.  But if you do a shoddy job on the end post, no amount of staples or other attaching the fence to the support posts will give you a sturdy fence.

Programming, as Jeff Duntemann points out regularly, is very similar.  It's relatively easy to create a program--even a large program--that is internally consistent.  The hard part is the edges--where the program interacts with the outside world, be it the user interface, the hardware, or some other program or piece of software.  The edges make all the difference.  If you have fragile interfaces on the edges, your program will be fragile regardless of how structurally sound it is internally.  Good, clean, strong interfaces won't save a bad program (although they will certainly help), but without them the program is lost.

I'm always surprised when I see a junior programmer, often one who is working on his first major assignment, designing the interface to an important edge in a software project.  I realize that developing interfaces isn't the most glamorous programming job, but it's the most important.  Design of interfaces should be done by experienced programmers who then leave the implementation to juniors.  The juniors, in turn, learn why certain design patterns are used and gain a better understanding of the entire software design process.  This is especially important when developing an API that will be used by multiple projects.  It takes knowledge and experience to develop an interface that's complete, minimal, and easy to use.  It's not something that should be left to inexperienced programmers.