I have been watching many salesmen lately, and I realize that all they do is construct a Straw Man argument for you as to why you should not buy their product, and then they tear down that Straw Man right in front of you, hoping you believe their argument and consequential dismantling of it. The good salesmen and saleswomen have made an art form of this play.
Usually, the Straw Man that the sales person constructs is your own old and inferior item. It is your own [vacuum/car/house/dress/furnace…] thing. The Straw Man has to be convincing enough that you can look at it and say “Yes, that is my [vacuum/car/house/dress/furnace…] thing.” Yet the Straw Man also has to be flimsy enough that it can be torn down quickly and completely, thereby showing you how inferior your thing is compared to the new thing.
Let’s see what this looks like with a vacuum salesman for example. One of the first things the sales person will do is ask you what you like about your current vacuum. What do you dislike about it? This helps the salesman direct his conversation and arguments to play up what you like on the vacuum he wants to sell you, and downplay what you don’t like, or show you why that is no longer an issue. Next, maybe he will ask you to get out your old vacuum. Now, with all the good salesmen I have seen, they will go into an education phase. They will teach you about your current vacuum, but focusing on what their new vacuum does better than your old vacuum. They will teach you about airflow and suction, filters, intake, exhaust, bags, containers, etc. Basically a breakdown of your vacuum. Next, they will jump into a demo phase. They will take their vacuum and essentially run it side-by-side your old vacuum, showing you the differences (but really only the differences that are in favor of the new item). Up until this demo phase they have been building up a Straw Man. This is the point when they tear it down.
What does this have to do with software?
A Software Architect has to do much the same thing. We basically have to sell an architecture. We have to get developers to buy our architecture. We have to get the business to buy our architecture. Sometimes we may even need to get end users or clients to buy our architecture. We are selling a vacuum, but the hard part is that none of the people we are selling the vacuum to actually own a vacuum, or even want to own a vacuum. They only know a vacuum as this thing people talk about, but nobody really knows what it does or what it might be good for, just that it sucks. Yet even though they do not want a vacuum, we must somehow convince them that the vacuum is the most important piece of equipment in their entire house; otherwise they will go and spend their money on a new fridge, or furnace, etc.
Developers
When selling to developers, we may ask them what they like and dislike about their current programming model. How long does it take to compile? How fast do the tests run? Is it easy to deploy? Is it easy to debug? Does it perform? Does it meet the needs of the business? How easy is it to change? Sometimes, developers do not care about all of these items. They may not care that the thing is nearly impossible to deploy, because they are not the ones deploying it. They may not care if it meets the needs of the business if it is relatively easy to change to add the features the business is asking for right now. How do we convince them that moving away from a monolith and onto a distributed architecture is something they need to buy?
Developers may like that they only have to deal with one code-base, or one project in their IDE. Maybe they like being able to go to one log file to see everything going on in the application. Maybe they like spending all their time fixing bugs. Once you know what they like, then it is time to find out what they do not like. They don’t like that it takes half an hour to compile. They don’t like how often Eclipse crashes trying to load the project.
The process so far was just to give you some directions; some points to really start a discussion from. The developers’ likes of the current architecture will be what they push back against the new architecture with. The dislikes are questions they will most definitely ask about, and probably more than once. But the thing is, we have to build a Straw Man. Not the Straw Man that subtly misdirects an argument, but a Straw Man that stands in for a real thing, and can be torn down, showing that the new way is an improvement.
Originally Posted on my Blogger site June of 2017