Articles Feed

Why Software Development is a Craft

by: doug | October 22nd, 2009 | 4 comments »

Craftsmanship has been used as a metaphor for software development. Pete McBreen argues in his book “Software Craftsmanship” that craft is a better metaphor for software development than is engineering or science.

I take the association one step further and claim that it craft is not just a good metaphor for software development, but that software development is literally a craft.

The Hand and the Eye

A key facet of historical craft is the intimate connection between the hand and the eye. A furniture maker cuts a joint with his hands, then fits the two pieces together. If the alignment isn’t perfect, he sands and trims and fills until the joint is true. It’s a cycle of shaping and observing. A glass blower turns the bead of molten glass over and over in a steady rhythm as she shapes the glass towards its final form. Her eye informs her hands and she constantly sees the effects of the changing speed and angle of the turning rod.

Code is a physical thing. Though technically code is nothing more than some states stored on a fast spinning magnetic disk, it is just as physical as a lump of clay. Consider the language used when talking about code. It is touched, shaped, moved, broken, cut, pasted, fiddled with, tweaked, and played with. It is the physicality of code that enables the feedback between the hand and the eye. It is touched and a change is observed.

This is why Test Driven Development is such a key practice in software craftsmanship. There was a time when a programmer would write a bunch of code and try it out hours or even days later. The time between making something with the hand and seeing the results was long. When a programmer writes a little bit of test code and runs it, then a little bit of production code and runs it, this cycle shrinks to minutes or even seconds. The connection between the hand and the eye increases. The craftsman immediately sees the work of his hand.

Making

Another element that makes software development a literal craft is that software development is a process of making. Contrast that to engineering. What is the primary activity of an engineer? It is design. A civil engineer designs a bridge that an ironworker builds. The electrical engineer doesn’t typically etch or populate the circuit board. She designs a circuit that is printed on a board and populated by either machine or technician.

In contrast, the software craftsman doesn’t just design the software (though she does do that), she also makes it. She writes the code that makes it work. There is little manufacturing involved in taking the made software and putting it in the hands of the person who will use it. Sometimes there is a deployment to a server or perhaps a CD is burnt and packaged in a box. But often even these tasks are performed or automated by the maker herself.

Material

Historical craftsmen have always been makers. The potter makes a vessel; the blacksmith, a horseshoe; the weaver, a garment. These makers have always had close connection to the raw material of their work: the wool, the iron, and the clay. What then is the raw material of software craftsmanship? What is the material of which software is made?

The material of software is language. Java, Ruby, C, Scala, Clojure, etc.: these syntaxes are the medium in which the software craftsman works. What makes this media so interesting is that the materials themselves are composite materials made of more primitive materials. Beneath Ruby code lies an interpreter built in C which is compiled by a compiler. The most basic of which is built in an assembly language which is assembled by an assembler which is built in the most primitive machine language which is read directly by the computer’s processor. Each new language emerges out of other languages as craftsmen explore the materials and invent new ways of combining and deconstructing what they have at hand.

It’s similar to metal alloys like steel. Iron is combined with other metals to make an new raw material whose strength enables the construction of enormous buildings. Each new language innovation gives the software craftsman a new, more powerful material from which to build both larger and simpler systems.

Tools

A discussion of software as craft isn’t complete without mentioning tools. A software craftsman does deal with the hardware on which his software runs, but the more interesting tool set is the software that the craftsman uses to write code. The text editor or development environment, the unit testing framework, the continuous integration system, and the acceptance test system are the tools of the software craftsman’s trade. Because these tools are built from the same raw materials as the thing being made, software craftsmen have the ability like historical craftsmen to be tool makers.

Learning

The final argument for treating software development as a literal craft is the way in which it is learned. A traditional college education in computer engineering or computer science produces graduates woefully unprepared to develop software. The best way to learn how to make software is to sit down with someone who knows how to do it and learn from them. This is currently being displayed in many shops throughout the world that are embracing an apprenticeship model for training and growth. This model has been used for centuries to pass on crafts from one generation to the next.

Software is Craft

The Software Craftsmanship community is growing and having some fabulous discussions. I think that this is largely a result of people not just using craftsmanship as a way to talk about or explain software, but embracing and practicing software as a literal craft. The historical crafts have begun to inform us in the software craft and have helped us develop our practice. Most metaphors break down when taken too far, but software-as-craft isn’t losing any steam. Perhaps that is because the association is more than metaphor and software really is a craft.

Limelight 0.5.0 Released

by: micah | October 19th, 2009 | 0 comments »

Today we released a new and exciting version of Limelight. Just a reminder, Limelight is a user-interface framework for Ruby. Included in this release are not only some new features, but also a new means of production(application) distribution called Playbills, and a snazzy production that documents the Limelight framework.

Playbills

Playbills is a hosted repository of available Limelight production. When you open the Limelight application, Playbills will open automatically (assuming you’re connected to the internet) and display a playbill for each production. Each Playbill provides a brief description to help you decide if you’d like to open the production. When you’re convince, click on the provided button. The production will be downloaded an opened in Limelight. Pretty nifty I think.

Limelight Docs

Among one list is a Playbill for our own Limelight Docs production. We’re quite pleased with this one. It’s a swiss army knife of documentation that should make it fairly simple for developers to build their own Limelight productions. You’ll find descriptions, walkthroughs, RDoc, and dynamic sandboxes where you can experiment with the features right inside the documentation! What’s more, the RDoc is loaded dynamically from Limelight’s runtime… You can’t get more up to date than that!

Status

Limelight has been a thrilling side project to work on. I’m very pleased with how it is turning out. We are using Limelight internally at 8th Light for a variety of projects. This release (0.5.0) is still a beta but the Framework is maturing rapidly. Although there are still a few rough spots, I’d certainly be willing to use it for production projects. Development on Limelight is active and the productivity advantages of using Limelight are hard to beat.

P.S. If you have a production you’d like listed on the Playbills server, let me know (micah at 8thlight dot com).

Pair Fridays

by: paul | October 6th, 2009 | 0 comments »

8th Light has always had an open door policy towards developers. When anyone has asked to come hang out at 8th Light offices, we don’t turn anyone away. We also invite developers to come in and pair with us. It has been a fun practice to get to know other developers here in Chicago as well as developers traveling through town. We would like to flip that practice around and invite anyone interested in pairing with 8th Lighters or just coming in to hang out.

Every Friday we have a noon lunch and learn (lunch provided by 8th Light) and then we will be available to pair for the afternoon. Want to come in and see how we work? Learn to use Limelight? Teach us something cool? Just hang out with cool developers?

Please RSVP with me (paul [at] our domain name) so we know how much food to order.

Reflection on Hangman

by: micah | October 4th, 2009 | 7 comments »

Last week concluded the Hangman Ruby Sparring Tournament. The results are below.

Unlike the previous Battleship Tournament, I put the effort in to write a competitive hangman player (of course he was banned from competition). This made things interesting. By knowing precisely what it takes to create a player, I was able to precisely tune the scoring metrics. My goal with the scoring metrics was to evaluate the code, without actually looking at it myself, and rate it’s quality/cleanliness on a scale of 0 to 100, where 100 was asymptotically impossible to reach.

It is not easy to score well on ALL the metrics. Each metric will push your code in a different direction some of them are opposing. For example, to score well on the flog metrics, you have to break your code up in to lots of tiny methods. However, extracting methods increases the amount of code you have which brings down the simplicity score. To get an overall high score requires compromising between opposing metrics over and over again. Realistically, writing clean code requires the same type of compromising between coding principles. I am thoroughly impressed with the high scores that people were able to achieve in this tournament.

In the end, I believe that the highest scoring players do fit many of the criteria for “clean code”. Which is to say that to metrics used to evaluate the code are fairly complete. However, there is one gaping hole. The highest scoring solutions look like this:

1. def b
2. @r.fill(0)
3. c
4. @l = @l.sort_by { |x| @r[x] }
5. end

People discovered that by using short variable names and method names, they could considerably reduce the “simplicity” of their solution. For this tournament, the simplicity score measures the code mass (compress all the code and count the bytes). It’s a fair metrics because in general, the less code there is, the less code people have to read to understand it. I especially like the fact that comments hurt the score. Anyhow, clearly the code above is not good code.

What’s missing is a analysis tool to measure “Readability” of code. I imagine such a tool would be similar to flog and flay in that it parses your code and examines all names used for variables, methods, classes, etc. When it finds 1-letter names like above, it punishes. When it finds names containing english (or other languages) words, or derivatives of other names, it rewards. For example, it I had a class named “Player”, that’s an english word which is readable. Good. Now a class named “ThingAmaBob” is not english but that not necessarily bad. And you’d expect variables with names like “mythingamabob” or “thingama_bobs” which would be good. There are plenty of ways to expand on the idea. Such a tool would bring our repertoire of metric tools one step close to completion.

####