The economics of aesthetics

Many will argue that it is just plain wrong to subject aesthetics to cost and benefit, at least until a certain threshold. Someone said, “An economist is someone who knows the price of everything and the value of nothing.”

But this is the reality of business. A product or service can be made just useful or it can be made useful and beautiful. As consumers, we frequently choose from varying degrees of form and function. However, things get more interesting in a B2B situation.

Clients agree to foot the bill for aesthetics to the extent it promises to help their topline. Funds are made available for aesthetics on a public facing website. The belt is tightened for an internal facing application. Vendors use the same logic. They spend money to make sure that their presentations are not only substantial but also aesthetic enough to impress clients.

What about the people who write code? They also have a sense of aesthetics. Their bosses don’t grudge them the inexpensive effects – standard tools that can ensure uniform indentation, nice fonts and syntax highlighting. But higher order aesthetics are a different matter altogether.

I mean lucid, performant code, fluent interfaces, pithy names, succinct tests and coherent classes residing in cohesive modules loosely coupled with their neighbours.

“Don’t just call these aesthetics”, I hear the indignant coders say.

“They confer vitality, suppleness, and longevity to the codebase.”

There is truth and perhaps some irony to this claim. Unfortunately, even the truth is appreciated largely only by the coding intelligentsia. As a result, efforts to secure these higher order aesthetics go unchallenged only as long as the development team stays on track for budget and schedule. As Stewart Brand said, form follows funding.

But estimates being estimates and competitive bids being competitive bids, there is many a slip between the cup and the lip. Screws get tightened,

“Enough gold plating already.”

Some will contend that effective visualization of internal software quality will bring about the necessary loosening of purse strings. Well, only occasionally. For one, a common (and sometimes legitimate) reaction is,

“Why did you incur technical debt in the first place? That’s not why I hired expensive consultants like you.”

But first, there is the question what makes for effective visualization. Should we show a tangled ball of wool versus a neatly wound ball in order to contrast the current cyclomatic complexity with desired state? Should we progressively untangle the ball in progress reports? Is it not enough to state in text that the industry standard is about 20 per 100 hundred lines of code and that we are currently at 45?

Should we depict a slummy urban sprawl for a monolithic codebase and gradually introduce suburbia with zoning as we modularize? Is it not enough to show a dependency structure matrix?

How accessible does a visual need to be before a non-technical/post-technical decision maker gets it? One kind of visual targets the recipient’s analytical faculty. Another kind targets their aesthetic faculty. Aesthetics are in vogue among consumer devices. I suspect this has spilt over to the kind of visuals favoured by IT decision makers.

They very people who scrutinize spend on aesthetics through the lens of the topline lean towards aesthetics when they ask their sub-ordinates and vendors to send them reports and presentations.