Craftsmanship and Software Development
ByIn a previous post I quoted a colleague who stated :
I like how they use the term “Craftsman” to describe what we do….[the craftsmen are] the ones who have taken the time to master the tools that have been made available to them to assist in their craft.
Craftsmanship in the manner used above, refers to an attention to detail and a pride in one’s work product. A craftsman is more than a worker – he or she truly cares that they do things right and to the best of their ability. I agree with this thought in principle, but I want to expand on it a bit and speak to one difficulty with software craftsmanship as a methodology.
In today’s technological world we need craftsmen, but we also need more than craftsmen. As an allegory, look at home building. We care about the quality of construction in homes that we buy. We certainly want to make sure everything is up to code and if we live in an area subject hurricanes, we want to know the proper standards and materials have been used in construction. We want to be sure that the workers who raise the frame, do the plumbing and electrical work and do the interior finish work are adequately skilled in their craft. That said, we would not hire a cabinet maker to do the framing, an electrical engineer to run the wiring or a rocket scientist to handle the plumbing. We choose the right skills and tools for the job at hand.
Software development is still in large part a craft, an art. We are not yet at the stage where every aspect of software development is reduced to a kind of binary assembly line, where unskilled workers assemble programs from software “parts”. True, there are some benefits we can receive from using prebuilt libraries or components, saving development, testing and maintenance costs as we will discuss below. But we still need good, skilled developers to do the heavy lifting. Software is not like machinery. For the most part, you design and build a machine to do one thing. Software on the other hand is much more multi-faceted and when starting a software design, there really are almost unlimited options available. A problem can be solved in many, many ways. A craftsman is needed to help choose an appropriate solution.
But we are also beyond the time when every piece of software must be built from the ground up. There are many commercial and open source solutions available that can jumpstart projects or that can provide the backbone for common application functionality. These solutions include things like nHibernate, Spring, and other persistence libraries that handle common operations in a manner that has been well-tested and which meets the needs of many projects. The Java community has made very good use of open source projects and libraries, some of which are now included in core Java. Why then aren’t these types of libraries used more frequently in Line of Business (LOB) applications? I believe business is often missing out on long and short term cost savings by not leveraging these open source or 3rd party solutions. One reason these solutions are sometimes not adopted (certainly not the only reason) is the inherent craftsman mentality of developers and architects. I call it the “But we can do better” syndrome.
You are probably familiar with the Pareto principle, also know as the 80-20 rule. In the cost-benefit analysis of software projects this rule can be stated as “80% of the benefit comes from 20% of the development effort”. What this means in practice: IT needs to concentrate on that 20% of the time and effort which provides the most benefit and spend a lot less time and effort on the remaining 80%. In reality, it is often difficult for technical people to do this. Why? The 20% tends to be more mundane from a technical perspective and there is a lot of interesting design and coding to be done in the 80%. There’s an old story programmers tell about the a programmer who said “I can write that function in 10 lines of code”. Another programmer said, “I can do it in 5 lines of code”. Finally, a third said “Well, I can do it only one line of code” and he proceeded to spend hours upon hours writing and rewriting the function until it worked with only one line of code. What is the problem with this story? The first programmer could have written the function in minutes, the second in an hour or two but it took the third programmer many hours to complete the task. On top of that, the third programmer’s code was so complicated and used so many programming “tricks’” that very few other programmers could understand how it worked.
The “We can do better” syndrome is difficult for business to fight. Better after all is well, better. If we can reduce the time it takes to execute a function by 500%, it should be worth the effort because of the performance savings. Right? What if it only took .5 milliseconds for the function to run before it was optimized? End users would see zero benefit from the added effort to increase performance.* But from the third programmer’s perspective, he did the right thing. He made the application more efficient according to his definition.
Programmers also tend to distrust code that came from an unknown source (or even from one of their colleagues). In the early days of distributed computing we had the grand notion of creating object libraries full of reusable code. The greatest obstacle we faced to reaching this goal was the unwillingness of developers to use another programmer’s code. They would rather create it themselves. There was always something that the library didn’t do or didn’t do “well enough” in their opinion.
The moral of the story is this: we must apply the same logic for selecting software solutions that we would in other areas of business. Good enough is good enough. If there is an open source library or 3rd party library available that meets the 80-20 rule and which will truly deliver on the project’s requirements, it should be strongly considered as an alternative to developing everything from scratch. In order to know when to use an existing library and when to build a new library, business and IT must work together, and IT must keep the business objectives as the first priority. On the other hand business must be clear about their objectives with IT. Those objectives are the measuring stick for evaluating software design alternatives.
* I am aware that in some instances such as recursive calls, .5 milliseconds can be a performance bottleneck. That isn’t the scenario I am using here.
Related posts:
