Why software businesses are hard

(Note: The original of this article is posted at my web site here: https://www.kencorey.com/flippin-bits/why-is-software-hard-business)

Lots of books, studies, talks, think groups, consultants and more have tried to figure out why software as a business is hard...but they seem all try to look at it from a single viewpoint.

I'm going to give you the secret to why writing software as a business is difficult.?Hard.?Nigh-on impossible.

Why??Perspective.?Multiple points of view (PoV).

I've attempted to show you why in the chart above.?Value from one's point of view tops out at 10 here.?The units are arbitrary.

The business folks start this chart on the left.?The absolute best thing they could get is an app that does everything their heart desires and get it /right now/. The longer the project drags on, the farther to the right and down the blue line goes. Why can't developers ever deliver anything?

Either the market opportunity will dry up because a competitor did release an imperfect but on-time project, the sales won't materialise, or the project will run out of money before delivering.

Note that the blue line continues below zero. A below zero value is a very real prospect...it means that the project is losing money for the business.

The developers enter this from the right.?There's almost zero value in giving something to the business on the first day.?We've not had time to scope, research, analyse, plan, divide into user stories, write tests for, fail, refactor, meet, discuss, and eventually deliver some software. Why do the business types always demand software before it's ready?

If the business demands it at the beginning it will have a near-zero value.?As time goes on, the value delivered (red line) slowly ascends.?At the far right, we've hit the perfect software: small, easy to maintain, well documented, maybe multi-platform and a joy to behold...and entirely too late.

By the time we've gotten that far our company has gone out of business.

The real value that a software project delivers is represented by the green line. The maximum value is the MINIMUM of either the red or blue lines.

The best we can hope for is to find the optimal mix: 'enough' software to scratch a business need, delivered fast enough to capitalise on the opportunity.

Admittedly not perfect software, and clearly not delivered on day 1.

There are ways to try to manage both lines to enlarge or prolong the sweet spot.??

You could throw more money at a project (whether that shows up as hardware, software, people, facilities, resources, campaigns, publicity, influencers, whatever...at the end of the day, it's all money) to give you a longer time period before the blue line starts to descend.?However, the farther to the right you go, the less effect throwing money at a project will have.

You can try reuse (internally with code or externally with libraries), or better tech, hardware or people to move the red line to the left.

No matter how passionately I argue that we *must* refactor code or that the project must deliver by Tuesday (even if the software isn't ready), I'm not going to be helping the business.

At the end of the day, we need to swap our points of view.?

If a dev looks at this from the pov of the biz guy, they'll be thinking how to move their bar to the left.?Descope, suggest alternatives, innovate to do things in quicker ways.

If a business guy uses the pov of a developer, he'll see that the quick win never really existed because it wasn't obtainable in the first place, and trying for it might have actually cost us the opportunity that really was obtainable, even if it were smaller.

This is the challenge that makes software difficult, and yet keeps things so painfully interesting.