Software development is very hard to grasp; it is hard for us, the people who are developing software but even harder for our clients. In the world outside software development things seem to work very differently and that gap seems larger if you have no idea what is going on when developing software. To explain the process to non developers and for non developers talking about software to their peers and back to us, there are unfortunate leaky abstractions of metaphors.

One the worst has been kind of introduced by the industry itself: components. Also building blocks and, when you talk to sales, Lego. Although components in the software sense do not mean what a lot of people think they mean, in day to day language about programming they have been piled on with plugins, portlets, webparts, gems, reusable app and to some extend plain libraries etc to mean that you can take a piece of premade software, put it in your project and strike off another feature in the list.

Sales uses this Lego metaphor during the sales process to get clients to buy products and services which are made by just clicking together a bunch of blocks we already have, preventing both high cost and bugs at the same time. No bugs as the Lego blocks were thoroughly tested at 100s of clients so they cannot contain bugs, right?

As software developers we managed to do this to ourselves with our great optimism. We were and often are the frontrunners in thinking software can actually be made completely composable. We have been making these software tools for non programmers since the 70s and keep making them in the firm believe one day software development will be like Lego. What is worse: we keep telling this to sales and marketing resulting in these great sales sessions.

But then the development starts. And even though these portlets were almost exactly what was needed or the RoR team told actually most of the functionality is actually only assembling a few 1000 gems together, the project is late, buggy, takes a lot more manhours than expected and in the timesheets the word ‘refactor’ seems to appear more than the word ‘the’. How is that possible if we were only glueing together premade Lego blocks?

Even though a lot of architects and developers drink their own koolaid in genuinly believing that this time it will be different, in reality, besides in ‘hello world’ like trivial cases, the metaphor falls flat on his face. Mostly because this abstract software science notion of components has been interpreted wrongly over time and that is getting worse still. So many clients opt for WordPress because ‘everything is already there as a plugin’; why does the project still cost $200k after esrimation and research by more conservative coders and why can a client not just click it together himself?

After the Lego metaphor has been peddled to the client and some sprint build of the project has been delivered, another favorite comes in;

The software has bugs and is not very fast, so when the client, having spent quite some cash on the project, comes in there are some discussions. Usually the agile approach, rightfully so, resulted in a large amount of changes of ‘stuff’ the client did not anticipate upfront.

The Lego didn’t exactly fit and because features are missing, it is anticipated at this point the project will take longer and thus cost more. This is the time when someone says something along the lines of: ‘when I have a house built, builders deliver in time and for the price we agreed on, how come … … ‘. This is related to the Lego and thus to the components we sold them, so this metaphor is partly our own fault again. But it also isn’t a very good metaphor for the case of the client and yet it is very persistent.

The thing is; houses are not software. Houses are often largely prefab (actual Lego!) and even if they are not, building houses is a rather clear process. And yet, I have known no-one who had a house built were the price was not higher and it did not take more time to built than agreed upfront. Why? Changes by the owner at a late time in the process. Yes, like software development, this doesn’t work well. The metaphor stands quite well if you use it from our side; say you have a house built, but there is no money for the foundation (proper architecture), you are building on swamp land (using flat files in a concurrent environment) and after the entire house was done, you want to add a nuclear bunker underneath (make the application work offline as well as online).

Another, worse, metaphor is exactly the same one as above but instead with a bridge. Now bridges are always late and over budget and that is without ‘changes’. And they collapse. So these are projects with people who know a lot about the physics of these kinds of structures and have calculated everything to a tee. And yet it is late and over budget. If they would be the same as software, with the amount of changes (I don’t like the shape of the thing, I want the pillars to be triangular!), it would never finish. Now we are getting close.

Software is very complex and the human interaction which leads up to making the software is very complex; the combination is actual rocket science and makes for this vastly complex landscape which usually cannot be estimated properly upfront as no-one knows what the outcome will be. In projects like houses and bridges, things which are more or less tried and tested repetitive processes, they cannot do it, so how is that supposed to work with software?

This brings us to, for me the worst metaphor; cars. “When I buy a car, I don’t get to pay more so why do when buying software?” “When I buy a Ferrari, I am not satisfied when I drive out with a Turismo!” Obviously this one is the worst as you are comparing a mostly custom product you had developed specially for you with a factory line mass produced one. The issue with this is Lego again; “Chris from sales told us that the process is like sticking the extras on a car with your ‘gems’, so I expect a FXX K with all the trimmings!”

When the client dictated the price and still has the car metaphor in his mind, you get classics like I recently encountered: a product made for a fixed price dictated by the client, everything else (scope, deadlines) flexible (in the contract), but when the delivery build was done, we got: “But a lot of features are missing here, we need a full featured delivery and we need it now or we’ll sue you for all the damages incurred for not having all those features!”. So I said, more as a joke than anything else; “I buy a 1983 Trabant for E250,- to drive in the F1 and will make the guy I bought the Trabant from responsible for me winning it or not.”, but he understood it now and we have a good business relationship after this.

Since that time I have been thinking more about how to turn bad metaphors into good communication aids with people who are outside of the engineering profession. Working with clients is fun and rewarding, but both sides need to understand what is at stake; software development can be a weird thing for a lot of people. Sometimes productivity falls to almost 0, sometimes it is very high; why? Sometimes a bug takes 1 minute to fix, sometimes it takes a week. The key to this is being transparent and communicating everything to the client and the team every step of the way and documenting every step so it is clear what you are talking about.