Craftsmanship

There's something beautiful in a well-built dovetail joint.  It works with the wood, relatively strong in all directions without any nails or screws to risk splitting.  It looks terrific, but that's ancillary - especially since these joints are often hidden out-of-sight, in the back corner of a drawer.  The real beauty is in how cleanly it works - as if the wood was intended to be joined that way.

By contrast, you can hold two pieces of wood at a right angle, and just pound nail after nail through them until they basically hold together.  It takes less time than a dovetail joint and will generally serve the intended purpose: the drawer will hold together (for awhile, at least).

Dovetail joints can be very challenging (almost impossible) to create if you don't know the right technique, have the right tools, and some degree of skill and experience.  They're one of the things that sets an experienced craftsman apart, and one of many things that makes truly well-crafted furniture harder (and more expensive) to build.

There's also something beautiful in well-crafted code.  Sometimes it's building classes which follow the expected paradigms of the platform on which they run.  Sometimes it's execution of a proven design pattern to solve a relevant problem.  (Stress "relevant" there - overuse or misuse of design patterns makes for ugly code, masquerading as elegance.)  It often follows the tenet, "Things should be made as simple as possible, but no simpler" (generally attributed to Albert Einstein).

I've been working primarily with ASP.NET for the last few years, so I'll use it as an (admittedly over-simplified) example.  Most ASP.NET development centers around a Page.  Each time a Page is requested, the framework follows a consistent series of steps to execute/construct the page: this is the "page lifecycle".  The framework incorporates a "view state" to track user-entered data, supports re-usable components called "controls", and supports event-based communication between the page and its controls.  Understanding these elements and how they work together are vital "tools and techniques" for building a well-crafted ASP.NET system.  If you understand them, you'll likely write code which integrates well with them, and you'll feel how the whole just seems to be "meant to work that way" - like a dovetail joint in wood.

By contrast, it is possible (I've seen it many, many times) for developers to build a fully-functioning ASP.NET system with only the barest understanding of those elements, and no concept at all of how they interact.  It's ugly and difficult to maintain, and usually results in a lot of "whack-a-mole" fixing of bugs (and causing more bugs in the process).  It's the software equivalent of "just pounding nail after nail into it".  But if you keep pounding at it, it will eventually work - like the nailed-together drawer - at least for awhile.

A furniture craftsman is perfectly capable of haphazardly nailing a drawer together - but he (or she) won't.  He takes pride in his work, and doing a "good enough" job simply isn't fulfilling.  Perhaps more importantly, he knows just how beautiful and fulfilling a well-crafted piece CAN be, and that knowledge makes doing "good-enough" work all the more painful.

In my younger, less experienced days, it gave me great pleasure just to get a piece of software working.  Often, my code was of the nail-after-nail variety - but that's to be expected.  I didn't have the skill, tools, or technique to write "dovetail joint" code.  Heck, at that time I probably didn't have the experience to fully appreciate the difference between the two!

However today, at the risk of sounding pretentious, I am a software craftsman.  I know how good software CAN be, when it is built with an understanding of its platform, and of common best-practices for using it.  Simply "getting the software working" no longer holds any excitement for me; designing and writing well-crafted code is the fulfilling aspect of my job.

So that's great, right?  Experienced craftsmen are MVPs of their professions, right?  When it comes to software development, I'm not convinced that's true.  I need to mull that over a bit - it will probably be my next post.