Tech Tempations During Economic Contractions

I've come to believe that software is neither an asset nor a liability.  It more like mechanized operations.  It's your factory floor, shrunk into an electronic Rubick's cube.  All the assets and liabilities that flowed through your physical operations have their analogue in software.  Your cloud bill is your rent amortization, electric bill, server and amortization, etc.  Your external data providers are your suppliers.

Post delivery running costs are often underestimated.  Running software requires maintaining hardware and skilled staff long after project delivery.  It's less complex on paper than a factory but can't function without some minimum staffing and budget year over year.  The cloud has helped hardware costs tend towards commodification and thereby resist inflation.

Labor however has proven more resilient.  Wage inflation is a significant contributor of gross inflation.  Inflation accompanies expansionary cycles.  Wages are generally tech company's largest expense.  Once faced with contraction, even amidst a layoff driven labor market reset, retained employees salaries do not mark to market.

It's easy for a company focused on scaling to over invest in software during an expansionary cycle.  Anyone who's tried has learned the hard way that you can't time the market.  Only in hindsight do we realize we were at the precipice of a correction.  If you don't expand aggressively enough you may lose to competition that does.

"A drowning man will even grasp for reeds."

【学习日本谚语!】日本のことわざ-溺れる者は藁をも掴む 

Temptation #1: Return to Waterfall 

No longer willing to tolerate the uncertainty of delivery, the larger organization demands that software development costs are known up front.  Engineers understand that this is an impossibility.  If they protest they're not being naysayers or defeatist.  Consider it a sign of competence and integrity.  It's when they don't protest that you may have a problem.

Software development is the exploration of an unfamiliar problem domain.  Engineers are like explorers of old.  They don't know how long it'll take to reach the New World.  No one's been there before.  If someone had, no one would be asking them to go.  Their financiers would buy, not build.

Agile was invented to address this uncertainty.  Rather than promising big and failing hard, it breaks up deliverables into small value add chunks and iterates.  Don't cross the ocean.  Tack along the coast refueling and reassessing frequently.  This reduces uncertainty.  It doesn't eliminate it though.  Software carries with it the risk of unknown unknowns.  This fact should be accepted and treated like any other risk.  After decades of trial and error, Agile is the best hedge we have.

Temptation #2: Wagile / AgileFall

This is when companies run Waterfall but convince themselves they're running Agile.  It's so common that the US government published guidance for dealing with contractors, "Detecting Agile BS."  It's rarely if ever intentional deception.  It's more likely due to a misunderstanding of what Agile is, lack of conviction to adopt it, or failure to execute.  Companies unwilling to accept the uncertainty of software development continue to demand costs are known up front.

Temptation #3: Seek Out a Panacea 

At the end of the Dot.com bubble, I worked on a project using Cold Fusion to build an online product.  The promise of Cold Fusion was that by using configuration and convention, it abstracted away much of the complexity and cost of software development.  It worked well as long as our use cases matched exactly the boiler plates the stack provided.  Deviation however, magnified cost and complexity well over the traditional approach.

Tools like these tend to appear at every contraction and fade to obscurity thereafter.  The lure is unquestionable.  They promise exactly what you need exactly when you need it.  It's prudent to exercise caution when adopting unproven technology. The fast follower strategy may be worth considering.

 

 

 

Comments

Popular posts from this blog

Is it Time to Become an ML Engineer?

Engineering Truisms

The Contemporary Yamanba