Ben Abernathy writes a poignant observation about computer science and the kinds of people that come (or don’t come) out of college programs.    The first group ditches computer science altogether, the second delights in making things work, but the third strives for something more elusive: elegance and beauty.  Ben is right to note that if you’re looking for beauty in software, you can very well end up a miserable idealist.

Personally, I’ve had to come to a place where I resolve to plant beautiful code wherever I can, even if it is surrounded by weeds I’m not allowed to pull.  Even when I fail at it, I find that the effort of striving to improve, rather than just make do, makes me a better and happier software engineer.

Having been in software for over a decade, I have found one easy way to spot the differences between coworkers and competitors in Group 2 (“Get it done”) and Group 3 (“Make it beautiful”): Regard, or disregard, for craft.

Doghouse Software

It’s pretty obvious when you look at carpentry, masonry, or cooking which people care about their craft, and which people just “got it done.”  Unfortunately, craft it much easier to see in the physical space than in software.  Even a gorgeous GUI can hide some unspeakably gnarly code.

I heard Grady Booch speak at Java One many years ago.  He said that most people build applications like they build doghouses:  Bang together some wood, and if the dog is mostly dry, you’re done.  Enterprise applications, he noted, are usually skyscrapers composed of a bunch of doghouses duct-taped together.

Doghouse software is built with little regard for craft.   This problem may not show up right away, but as soon as the requirements or use cases expand, the shoddy craftsmanship becomes painfully clear.   Ask anybody trying to retrofit web services on a legacy architecture, and you’ll see what I mean.

Process and Craft

Process, I must say, should not be confused with craft.  Craft should involve some process , but I’ve never seen process generate craftsmanship.  (I have seen beautiful code in CMM-4 shops and in startups.  I’ve also seen hideous crap in both.)  The difference invariably comes down to regard for craft by the individual.

Questions Asked and Unasked

“Does it work?”  If software is just a job, this is where a programmer stops asking questions.  If she cares about craft, she also asks questions like:

• “Can I prove it will work reliably? (It it testable?)”
• “Is it easy to use, does it eliminate excise?  (Is it usable, user-friendly, intuitive?)”)
• “Can I easily swap out visualizations? (Are there clear boundaries between model, view, and controller?)”
• “Will it work if it becomes modestly or even insanely popular? (Is it scalable?)”
• “Will it work if I have to add new features, or change the persistence layer, or play well in SOA?  (Is it modular, loosely-coupled, platform-agnostic, maintainable?)

These questions get at the heart of true software craftsmanship: Be in the business of building products that will stand the test of time, not one-offs with zero shelf life.

Application-wide craftsmanship can be, as Joel Spolsky rightly notes, “incredibly expensive. “  I firmly believe, however, that individuals can improve their craft and stay on budget in most situations. I have found that improving my craft improves my productivity and the maintainability of my code.

Go to the Source

Source code it often a great way to tell whether a programmer cares about craft.    Is it clean and easy to read?   Are design patterns leveraged?  Was attention paid to loose coupling, encapsulation, dependency injection?  Are there an appropriate amount of comments?   Are complex methods broken down into simpler ones?  Are there unit tests?  Does the code, and the compiled product, look like something the programmer took pride in?  Or does it “just work?”

Finding Craftsman

My quest for interviewing new hires is not just to discern talent, but a regard for craftsmanship.   It is rare that a candidate can present source code, however.  I’ve found it difficult to really learn in an interview how much a person cares about the quality of his work.

Joel of Joel on Software uses summer internships to find the kind of people he wants, but most companies can’t reproduce his model or, honestly, draw that level of internship talent.  And, lets face, it, you can’t bring in senior engineers as summer interns.

Can craftsmanship be discerned in an interview without having the source code?   If you have any suggestions, please share them in the comments below.