Reflections On a Decade In Consulting

11 Dec 2018

In every industry vendor/client relationships require careful management and these relationships can easily fall apart. However, I think there is something uniquely difficult when it comes to software.

The software industry is barely getting started if you compare it to other industries like commercial manufacturing (Henry Ford), or civil engineering (the Romans).

We remain at the beginning of creating truly re-usable building blocks of the software industry. It’s not for a lack of trying! In construction you can take for granted nails, screws, 2x4s, 4x4s, as well as building codes designed by mechanical engineers that say “You will not do …” and “You will do …” otherwise we slap your project with a failing grade. Many decisions have been made for you.

We don’t have nails, screws, and 2x4s. We might have something called Screw, and within it there is every single possible option a screw could have (length, thread width and spacing, head type, finish, base metal) and every single time you want to use Screw you need to make all those decisions over again. Some decisions you care about, some you don’t. And if you’ve ever wandered the halls of Home Depot there are some things you’ve never even heard of before!

In construction you know the cost of all your supplies, and you know what you’re paying for labor. So its fairly easy to make a fixed bid contract — cross your fingers that nothing goes wrong — and if it does, its easy to show the homeowner the problem and plead for more money. They even do it on HGTV!

But in the world of software there is a reason that fixed bid contracts are uncommon these days. Many, if not the vast majority, of the relationships between clients and vendors are time and materials (T&M). There are more unknowns, and the number of moving pieces is far greater. But I think the biggest problem, that “uniquely different” something, is a far greater knowledge gap. I may not know what screws to use on which project, but if you explain it, it makes sense. Software is so ephemeral that if you tried to explain why this one operation is so slow because the database query engine resorts to a table scan because it cannot combine the indexes, made of B-Trees, to get you the result set in a fraction of the time, your client’s eyes have glazed over. They slam the desk and say “Make it faster, that’s what I’m paying you for isn’t it?!”.

Clients pay you to just do what they want. They have zero incentive to understand what their vendors are doing. They just want results. Developers have every incentive to believe their clients, that they are a good and truthful people who understand their business, their processes, and what they want at the end of the day.

When developers finally get to the underlying truth of the matter, they have every incentive to explain what is happening to their client. However, the client has no incentive to believe the developer understands their issues — just do what I say. This isn’t a car where you can take out the broken water pump and show them, or point to the transmission fluid leaking out through a hole in the line. The client has every incentive to believe in forward progress just like every other industry. After you’ve instructed the factory to create one widget, making 1,000 widgets is a lot faster and easier right? There is no incentive to go back to the drawing board for version two!

It comes down to trust, just like every other relationship. But money is involved here. With a giant knowledge gap between two parties and money flowing in one direction that trust can quickly erode. Niceties and codes of conducts are absolutely necessary, but those cannot fix the structural imbalances in these relationships. It is easy to pick on details and specific events for when trust was eroded. But if you don’t realize the game you’re playing you can only keep juggling for so long.

In my opinion, there is one more structure we need to give to this relationship. One that alters the incentives at play. And that is a baseline understanding of being partners with your clients. Not just a vendor.

#Consulting SoftwareEngineering