These days I seem to be forming the view that the only good metaphor of software development is a dead one.
Here comes the topic as old as programming itself. An answer for “what is programming like?” question.
Programming is like civil engineering. Programmers are bridge-builders.
Programming is like magic. Programmers are wizards.
Programming is like writing prose. Programmers are writers.
Programming is like running a farm. Programmers are farmers.
Have I mentioned the oysters?
Are we done yet? It seems like everyone had come up with their insights already. Not surprisingly even, as it’s a joyful form of introspection. After all, if our programs use reflection1, why wouldn’t we? All those metaphors might entertains us. They might make for a challenging theoretical discussion2. They might lead to some interesting thought experiments and even inspire us on how to adjust the process of software development to better serve its gods of efficiency and shippability. It might seem that the programming metaphors are innocent tools of programmers’ self-awareness.
And they are. Until they aren’t.
The thing with the metaphors is that they stick. Once they’re in, they’re in for good. They couldn’t be easily removed from our vocabulary nor from our thought process. The more popular they get, the more repeatedly misunderstood they become3. The meaning they carry is read in unpredictable contexts and therefore dynamically changes. No author can imagine what places their innocent idea will be taken to.
What it takes the metaphor to stick though? I could run with “programming is like doing laundry”, but I doubt it’d get any traction. As I see it, the programming metaphors that do get popular appeal to common sense, seem useful / applicable and go well with the programmers’ self-image. Which leads to a rather disturbing thought: the more the metaphor fits the needs of a dominant group, the sticker they become. And the dominant group among the programmers are white, young, middle-class males.
Some metaphors got so widespread that we no longer think of them as metaphors.
Let’s take software craftsmanship, a movement dear to my heart.
So, what is Software Craftsmanship then? In a very simplistic way, we can say that software craftsmanship is a better metaphor for software development than software engineering. Software craftsmanship sees software as a craft and compares software developers to medieval blacksmiths.
A vision of an apprentice dedicating life to improving quality of their skills and achiving mastery is a powerful image. It’s a role-model that was used for identifing how to bring professionalism into software development. However, using metaphor as a vehicle for carrying values is a double-edged sword. It makes the message simple and concise, but also fragile to being rejected on account of metaphor. The meaning might be judged not by itself, but by how well the metaphor is carring it. The craftmanship in software craftmanship was therefore downplayed and now it’s rarely brought into discussion4.
Sandro Mancuso mentioned even more powerful and widespread metaphor deeply entwined in our language: software engineering.
The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
Wat?! In what universe is software engineering a provocative term? Well, it isn’t anymore, and that’s exactly the point. Since it was introduced, it became so obvious, that we call the university programmes by that name. When it was introduced, however, the aim was to make the messy world of computer programming more structuralized, more professional and more industrialized5. As the wonderful Recoding Gender book states, the term was aspirational. It was a metaphor consciously used to lift the young software development field.
However, once again, the metaphor came as a double-edged sword.
The byproduct of using software engineering term, as presented by Janet Abbate, was that the software development became less women-friendly. The traditional fields of engineering were taught at male-dominated technical universities and there wasn’t much of the gender balance in civil-engineering or automotive industry. When the programmers started to call themselves software engineers, they also started to judge themselves accoringly: “Am I a real engineer? How do I fit the engineering model?” It became a part of a self-image and started to be a distinctive factor in dividing between “us” and “them”. This is a well known mechanism. The metaphor was used in defining the group boundaries and apparently a lot of people have been left on the outsite.
Let’s look at one of the main current challanges in software development: the lack of diversity. It’s just a waste of time to list all the groups that are underrepresented in the field, so I’ll make it short: there is a lack of computer programmers other than dudes like me, white, young, males. The software development field is exclusive and I believe this should change6. Could we leverage the double-swordness of metaphors to bring us a little bit closer to that goal?
How can we use the metaphors to our own good? Let’s recap: for the metaphor to stick it must appeal to common sense, seem useful and go well with the programmers’ self-image. The forth factor that we need is that it’s inclusive and possitively associated among various diverse groups. It should ease the steepness of learning curve and show computer programing as a creative and gratifying activity that everyone can participate in.
Let’s talk about gardening.
Andy Hunt and Dave Thomas, authors of famous Pragmatic Programmer book introduced the programming is like gardening metaphor. I believe that adopting this metaphor can help building more inclusive and open image of a computer programmer. It could widen the group boundaries far enough to make it way easier for current minorities to grow.
Could it stick, though? Well, the answer whether it applies to common sense, i.e. fits well with the everyday experiences of programmers, is well delivered by the authors themselves:
You do plan. You plan you’re going to make a plot this big. You’re going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You’ve got a great plan, a whole design. But when you plant the bulbs and the seeds, what happens? The garden doesn’t quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You’ve got to prune it. You’ve got to split it. You’ve got to move it around the garden. This big plant in the back died. You’ve got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don’t look good next to each other. You’ve got to transplant this one over to the other side of the garden.
All that pruning, splitting and transplanting sounds an aweful lot like the refactorings we do every day. Isn’t the whole microservices idea7 aiming at introducing the ability to change into architecture so that the organic growth of complexity in both feature set and implementation would never cause the whole project to wither? Isn’t TDD8, the technique for shortening feedback loop, based on small increments and reacting to them the way that the gardener reacts to small changes at their garden?
The organic, change-oriented, feedback-based approach to software development is so useful that it has manifested itself in Agile movement. Since the early 2000’s agile became the leading management methodology and programming is like gardening fits its world perfectly. We must be ready for a fast adaptation to the changing requirement the way that the gardeners must adapt to changing weather. We must accept that we don’t completely control the software development process the way the gardeners don’t control animals, wind and bugs. We must know out limits, the number of storypoints we can take on a sprint, the way the gardeners must know how big the garden they can cultivate.
So we can see how gardening plays with programmers everyday life. What about the self-image?
The fact remains that more than 15 years after being introduced it’s still not a dominant metaphor in the computer programming. Although generally it’s well received and I’m not an only fan, I’ve yet to see a computer science program named “software gardening”. Could it be that most of the programmers don’t want to think of themselves as gardeners? Or is it just not popular enough and we only need to promote it more?
It might be that the gardening is not as universally possitively associated as it seems to me. It could be rooted in a working class instead of middle one. It could be associated with manual labour rather than intelectual one, with blue collar instead of white. It could be seen either as recreational or exhausting, depending on one’s background. Maybe we need to be more specific: programming is like on orchard, programming is like a botanical garden. I fear, however, loosing the simplicity and generality of gardening. I’m not sure if I see a solution.
What I do see, hovever, are the possibilities to use this metaphor to make code schools more inclusive, to destroy the myth of computer programming as an ivory-tower and genius-requiring skill and, last but not least, to make the programmers think of themselves a little, just a little less seriously.
What a win it would be.
Reflection is an ability of computer program to identify what parts it consists of and modify itself if needed while running. For example a mobile app can reflect on what sections of the screen have been loaded and use that knowledge to hide or show particular features. ↩
Although, let’s admit it, a slightly boring one. ↩
I do not mean “misunderstood” in a you didn’t get it way, rather the author didn’t ment it way. I’m not a fan of carving the intended meaning in stone. ↩
Sandro Mancuso writes a few pages later: “Over the years, I joined some of these debates and spent a lot of energy trying to convince people why Software Craftsmanship is a good metaphor and why software development is a craft. As I was getting more involved with it, I realised that it does not really matter. This is by far the least important thing we should be discussing. I personally like the metaphor and treat software development as a craft but what I really find important and care about are the values that Software Craftsmanship tries to promote.” ↩
In the same document: “The software industry is not industrialized. We undoubtedly produce software by backward techniques. We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters. Software production today appears in the scale of industrialization somewhere below the more backward construction industries. I think its proper place is considerably higher, and would like to investigate the prospects for mass-production techniques in software.” By M.D. McIlroy, Bell Telephone Laboratories Inc. ↩
Even if one don’t see the increase in diversity as morally proper, there’s a pragmatic argument: technology is a form of power. And the more distributed power is, the safer I feel in terms of whether it wouldn’t be abused. ↩
The idea is to build the application not as a monolith, but as a system consisting of many small, independent elements communicating with each other. It usually makes the development of the application harder, but the changing and maintaining way easier. ↩
Widespread technique for writing code in which the programmer starts by writing a test before writing the code that implements the functionality being tested. ↩