"Much complexity has been deliberately created, to encourage consumers to pay more than they need, or expected." John Kay, The Wrong Sort of Competition in Energy
Modern software assets are complex in both their technical composition and their means of creation. They are built with multiple programming languages, are expected to conform to OO standards and SOA principles, make use of automated tests and a progressive build pipeline, require a diverse set of skills (UX, developers, QA analysts, etc.) to produce, are used on a multitude of clients (different browsers or native client apps on PC, tablet and smartphone form factors), and are deployed using automated configuration management languages to a combination of physical and virtual environments (cloud and captive data centers). Software is more complex today than it was less than a generation ago.
Complexity compromises both buyers and sellers of technology services.
Buyers suffer an information gap. Few managers and fewer buyers have first-hand experience in one, let alone all, of the technologies and techniques a team is - or should - be using. This creates information asymmetry between buyer and seller, manager and executor. The more diverse the technologies, the more pronounced the asymmetry.
Sellers suffer a skill gap. Because the demand for software is outstripping the supply of people who can produce it, experienced people are in short supply. There are more people writing their first Android app than their second, more people making their first cloud-based deployment than their second. There are more blog posts on Continuous Delivery than there are people who have practiced it. There are more are people filling the role of experience design than have designed software that people actually use. And while long-standing concepts like OO, SOA and CI might be better understood than they were just a few years ago, a survey of software assets in any company will quickly reveal that they remain weakly implemented. In a lot of teams, the people are learning what to do as much if not more than doing what they already know.
"Such information asymmetry is inevitable. Phone companies have large departments working on pricing strategies. You have only a minute or two to review your bill."
Information asymmetry favours the seller. Sellers can hide behind complexity more easily than the buyer can wade through it: the seller can weave a narrative of technical and technology factors which the buyer will not understand. The buyer must first disentangle what they've been told before they can begin to interpret what it actually means. This takes time and persistence that most software buyers are unwilling to make. Even if the buyer suspects a problem with the seller, buyer hasn't any objective means of assessing the seller's competency to perform. Where complex offering are concerned, the buyer is at an inherent disadvantage to the seller.
"When you shop, you mostly rely on the reputation of the supplier to give you confidence that you are not being ripped off."
Technology buyers compensate by relying on proxies for competency, such as brand recognition and professional references of a selling firm. But these are controlled narratives: brands are aspirational visions created through advertising (although "Go ahead, be a Tiger" didn't end well...), while references are compromised by selection bias. A buyer may also defer judgment to a third party, hiring or contracting an expert to provide expertise on their behalf. In each case, the buyer is entering into a one-way trust relationship with somebody else to fulfill their duty of competency.
An buyer inexpert in technology can compensate better by staying focused on outcomes rather than means.
Match cash flows to the seller with functionality of the asset they deliver. You're buying an asset. Don't pay for promises, frameworks and infrastructure for months on end, pay for what you can see, use and verify.
Look under the hood. There are plenty of tools available to assess the technical quality of just about any codebase that will provide easy-to-interpret analyses. A high degree of copy-and-paste is bad. So is a high complexity score. So are methods with a lot of lines in them.
Spend time with the people developing your software. Even if you don't understand the terminology, what people say and how they say it will give you a good indication as to whether you've got a competency problem or not. Competency is not subject-matter-expertise: technology is a business of open-ended learning, not closed-ended knowledge. But the learning environment has to be progressive, not blind guesswork.
Accept only black-and-white answers to questions. Most things in software really are black and white. Software works or it does not. The build is triggered with every commit or it is not. Non-definitive answers suggest obfuscation. "I don't know" is a perfectly valid answer, and preferable to a vague or confusing response.
An inexpert buyer is quickly overwhelmed by the seller's complexity. A buyer who stays focused on business outcomes won't dispel the seller's complexity, but will clarify things in favor of the buyer.
