Should Software Be That Scary?

Fear of the not-every-day

Placing your fate in someone elses hands is a scary thing, say, having surgery. Placing your car in the hands of a mechanic is perhaps not as scary, but still a bit intimidating. Eating a dish of chili prepared by someone else is… meh. We do that every day, and it’s really no big deal.

Why is it that we worry about certain things more than others? I mean, if the brakes fail on your car, it’s likely to cause as much discomfort as having a few stitches taken out. And a dodgy batch of oysters may not be life threatening, but we don’t seem to worry about it at all when we are seated by the maître d’. We trust the chef and the kitchen staff to be professionals. The thought of spending hours hunched over the porcelain throne doesn’t occur to us, even though I’d rather have a few stitches taken out, given the choice between the two.

There are several explanations to this, many of which have been researched by highly skilled teams. I am neither a team nor highly skilled in the area, so we won’t get to deep into it. Suffice to say, large parts of the explanation has to do with familiarity and exposure.

We eat food prepared and handled by others several times a day. If we were to worry about it every time we took a bite, we’d quickly turn into nervous wrecks.

We may not serve our cars several times a day [insert joke about Italian car brands here…], and to most of us, cars and engines and such are mysterious creatures that shouldn’t be tampered with unless absolutely necessary. And so our anxiety level increases somewhat compared to the eating example.

And finally, we (hopefully) don’t undergo surgery all too many times in our lives. And even if we were to disregard the imminent pain, the sheer unfamiliarity of the situation is intimidating to most of us. Even more so than having your camshaft refitted on your old VW.

With regards to development

But this article is about software development. What about software development? Why on earth is software development scary? It will (for the most part) not cause stitches, failing brakes or even a mild case of colon blow.

And yet, software development is still scary, because it’s unfamiliar territory. It may not be obvious to you and me, since we probably work in that domain. But rest assured, the vast majority of people have never seen a line of computer programming code in their lives. Least of all written one themselves.

Let’s view this from the perspective of someone who would like to hire you and your team to develop a custom peice of software. Perhaps a scheduling-whatever and a bit of webpage-something to go along with the database-thingamabob.

Most software developers (including me) fail to see the situation this customer is in. Unless they have gone through this several times before, they are likely to feel exposed and vulnerable in this situation. Remember that time the car mechanic with the greasy coveralls told you he had to “replace the broken carburator filter for the tail spring suspender on both the port and starboard sides, or the whole thing was gonna blow? And it’s not gonna be cheap!” Yeah, that’s how most people feel when they talk to developers. (If you know a thing or two about cars, just pretend I never fell for that bullshit)

So while they stand there, naked and scared, in a land of scary Database Monsters and Code Dragons, it is easy to think that our job is to wring a technical spec out of said customer and then disappear into our comfortable world of code for as long as we damn well please, until we can emerge with a fully formed creation of glory.

And it is our job. At least part of it.

But there’s more to it than that.

The problem, should we chose to accept it

In a time where computing power and data storage is cheaper and more accessible than ever, most customers are not worried about whether or not a custom CRM tool can be created or not. They are worried about whether or not we have understood their problem, and if we can help them to deliver a solution. Our job is not just to develop a solution to the problem, it is also to communicate and build a sustainable relationship with the customer.

This may be the area where we perform the worst. Time and time again, I’ve seen developers completely neglecting the part where we try to understand what problem the customer really is having.

And those times we do, we fail to communicate this to the customer, who will still feel left out.

Developing custom digital solutions is a costly endeavor for most businesses. Yes, it comes with enormous potential, but to anyone who shells out thousands of dollars, caution should be paid. As developers should recognize that our customers are in this situation, and consequently:

1. Make sure that we have understood the customer’s pain points and problems
2. Comfort the customer by showing them that we have achieved bullet 1.

That was easy! At least defining those points was easy. Now comes the hard part of coming up with an actual implementation.

And the solution…

Unfortunately, that is a totally different beast. And what’s worse is that it all depends on the circumstances. Who the customer is, what the problem/solution is, time and resources required etc.

Depending on those things, the two bullets listed above could be taken care of during a 15 minute Skype conversation, or it could be a project in and of itself, spanning several months. But regardless, as developers, we must keep this aspect of the business in mind when we talk to customers. Do not leave your customers out in the cold, make sure to continuously touch base on how the solution is coming along.

During those updates, always keep an open channel where the customer can provide feedback and ask questions, and encourage the customer to use that channel. Used correctly, this would be the perfect place for your customer to air concerns if he or she notices that the problem has not been properly understood by us, or that the requirements for the solution has changed.

A surefire way to discourage your customer from engaging is to give them access to a backchannel, only to ignore all the requests they put on there. So make sure to use it properly.

Once we have made sure that those two bullets have been handled (1. Understand the problem, 2. Reassure the customer that you really have understood the problem), then we can start with the rest of the work. You know, the parts that we love. Deciding on a tech stack, hacking late into the night and so on and so on…

I admit, I’m a bit disappointed myself here. I would have loved to give you an easy laundry list of action points, and get this thing out of the way, but I’m not sure there is one. Perhaps I will revisit this part with a more in-depth solution section later on. Make sure to connect to me if you’d like to see a follow-up.

And finally. For the love of Cheese, don’t give your customers that kind of bullshit about busted injectors on the database controller modules, and that it ain’t gonna be cheap. It’s just another way of flushing trust and confidence down the drain. Keep it real, boys and girls.

(Feature photo: Seongbin Im)