After my two-year hiatus in which I decided to build something with brick and mortar instead of with software, I finally find some time to work on other things that interest me again.
One of the things I have thought about in the last couple of months/years is the art of development. There are millions of books out there covering the subject of how to develop well. Some concentrate on coding, some offer frameworks and some propagate methods.
Having developed software for over 15 years and now contracted out software development over the past 3, I’ve realized a couple of things I feel I should share with you.
Firstly, let me start with a conclusion: development is a craft. Once you start thinking of it in this fashion, you can compare it with other crafts and see how software development can fit into this. My favorite craft I like comparing it to, is blacksmith or carpenter.
Hiring a blacksmith or carpenter barely happens anymore today. If, then it is because someone is seeking something unique. How did this develop? You can take a page out of the industrial revolution for an answer.
Before the industrialization, there were masters of their craft and nothing else. They designed the product based on customer wishes, created it – often with help of apprentices and journeymen. Depending on the experience and skill of the craftsman you either got good or bad results. The really good ones earned a lot, the really bad ones made a living. The main point is that the results strongly depended on the person you hired.
Then the industrialization and mass production set in. Initially, there were workshops where every craftsman worked one station doing the one thing over and over building on the results of other. On the one hand it increased overall productivity, on the other it started creating hierarchies and reducing the importance of the individual.
In the end the labor was divided up to a point where the performance hardly had any impact on the overall result. The results were always the same, everyone was exchangeable and machines took over more and more of the work.
What does this have to do with software development? The development lends itself readily for parallels with the industrialization.
Books such as Clean Code or Design Patterns are in essence crafters swapping ideas of how to solve particular problems. They tend to be prescriptive and the developer must have some skill to be able to use the described solutions.
Frameworks tend to fall more into the class I would term workshop or early automation. They reduce implementation depth for the developer who delivers the solution, improving overall productivity in the process. It still requires skill and knowledge to use the components, but as many very popular frameworks (.NET or the JDK comes to mind) prove, you don’t really need to know all that much to use the things. Another candidate for this category are things like Continuous Integration and other development approaches which focus on the how instead of the what.
The dream of every person paying for software development would be to have a factory which assembles the software on the production line and you receive a fully vetted, shrink-wrap ready result.
In fact, there have been several attempts at this. One I remember vividly is the software factory analyzed by Jack Greenfield. (article here) In fact I liked several of the points he brought up so much, it formed a part of what I’m getting at here. I don’t believe he found the right solution – many have tried to build the equivalent of a factory in software and haven’t been able to make it work. The examples often used it the car factory where one can choose between many options but deliver the same base product. I find these examples wrong and misleading. They fail to compare the right steps with each other. Software development is the equivalent with designing the car. The step of mass production is creating the delivery package and copying this.
What does this mean for you as a developer? Well …
- Improving your craft is an important part of your education. Realize though that this has its limits in term of overall impact.
- On team scale one can improve overall productivity by using techniques that fall in the area “workshop”. This generally requires time and effort to create as you are i.e. setting up a process.
- Don’t believe you can set up a factory. Every sales pitch in that direction I have seen were just that – a sales pitch. If you really do figure out an effective method – contact me. I would like to be in on the millions.
Bottom line, be very clear on what kind of project you are working on. If this is a one-off, two month effort is it really worth the effort to set up a workshop? Do you really have to think of where to build in hedges for further development? Or is maybe “KISS” the answer?
On the other hand if you are writing a 1000+ days of effort, it might be worth the initial investment to gain productivity and insure that you can deliver a solution even when people leave the project or similar. It also is worth the extra effort to hedge against change as such large software tends to continue to live for years on end. Quick and Dirty create more problems than they solve.
Think strategically, don’t believe that a solution that worked the last time will work every time and make sure that you have a wide selection on strategies you can pick from.