Assembling software: Craftsmanship style

Producing valuable, working software is an art. Practicing this art involves intuition (insight), talent and craftsmanship, like practicing any other art. The main principles of this craftsmanship, shared by many other craftsmen, are “know your tools and materials” and “less is more”.
The recent blog by Lars inspired me to write about my perception of craftsmanship in software development.

A feature that this art has in common with most performing arts (like theater and dance) is that it is a collective art form. Producing valuable software is a group effort. Talents necessary to cooperate in such a “performance” are thus both technical and social. Talents for communication and collaboration are at least as important as technical talents, like thinking in abstracts.
Intuition is used mainly when searching for solutions. Activities that require intuition are planning and design. It might be weird to rely on intuition in such an academic and technological field as ICT, but decision making in a non-deterministic world always relies heavily on intuition. I would say that although many of the materials that we use in ICT are deterministic, the context in which we develop software is obviously not. Crucial decisions about software projects are rarely about the materials and even if they are, information about the materials is mostly incomplete and not exact.
The most important contribution to a software project is craftsmanship. Many software projects don’t even feel like art creation in progress, but more like factory work. This is not uncommon; most art forms have a practical counterpart where the same craftsmanship is applied in a less esthetical form: furniture production can be seen as a practical application of sculpture, sharing much of the craftsmanship.
Craftsmanship is supported by two principles: “Know your tools and materials” and “Less is more”.
Materials in software development are mostly the programming languages and constructs we work with. This should be very broadly interpreted: Java, .Net and Ruby are materials, but so are SQL, HTML and XML. You could even think of design patterns as material.
In software development there are a great number of tools. They also come in all shapes and sizes. Of course your computer is a tool, but so is your IDE, the database and the third party libraries you use. It’s not that important which tools you select for your toolbox, as long as you know them intimately and they constitute a complete toolbox. This is especially true with respect to the third party libraries you select to build your software with. To be able to unleash the power that is doubtlessly encapsulated in this craft fully assembled library, you have to know what its strengths and weaknesses are and how to make your code interact with it.
The “Less is more” principle is applicable on many levels, ranging from the project level to the code level of software development. The fewer modules you identify in your design the better. The fewer teams you have in your project the better. But on the code level, this principle is most prominent. The fewer lines of code you write to solve the problems the better. Don’t get code happy. Ultimately, the code you write only glues together your business logic and the third party libraries that you use. Most of the projects time is invested in implementing the core logic of the problem your trying to solve. The rest goes into configuring and tweaking the code level infrastructure. You might have to write a Hibernate UserType, a Spring BeanFactory or a XStream Converter once in a while to make the tool suite your particular need. Don’t hesitate! As long as you know the tool intimately, you’ll feel perfectly happy writing the glue code that will live deep down in its core.
This is assembling software craftsmanship style. Focus on the core problems in your domain. Wield your tools wisely and glue them tightly onto your own code.