That sinking software feeling

05 Sep That sinking software feeling

Editor’s note: This is the first of a planned series of six short articles for executives of software-intensive businesses.

What is a “software-intensive business?”
I think a list of attributes of software-intensive businesses (SIBs) is easier to understand than a formal definition.

• SIBs don’t explicitly license software or sell software-development services.
• SIBs are up to something that causes them to pay programmers on a more or less regular basis.
• SIBs’ software activities are significant enough that they hear about it from customers and/or see it on the income statement the software assets are mismanaged.
• SIBs don’t consider software development as a core competency.

SIBs get in trouble because software is an unrecognized key asset, and no one on the executive team really understands how to manage it.
Water in the boat
Most SIBs learn that they are indeed Software-Intensive when they find themselves thigh-deep in metaphorical “water in the boat.”

• Loss of business momentum – Declining ability to respond to customer requests for new products and services.
• Rising programming costs – New features take longer and cost more.
• Internal strife – Conflict with the programmers, and stress and turnover among them.

Without an understanding of the software-development process and how it goes wrong (the holes in the hull), it’s easy for management to take ineffective – or worse, counterproductive – corrective actions, without addressing what’s causing the problems.
Holes in the hull
Some common holes in the hull are:

• Technical debt – Brittle software because the programmers borrowed time from the future, because of a lack of discipline in the face of typical business pressures.
• Drive-by requirements – Each customer problem or request immediately becomes a software requirement, with priorities changing daily.
• Lack of trust – Effective communication drops, even as the emotion and number of words increase.

The programmers see the holes appearing, but they find themselves shouting upwards (in terms of authority) in a language the executive team doesn’t understand. The programmers themselves might not even understand where the holes are coming from.
Auger Sharks
To my knowledge there’s no such thing as an auger shark in the sea, but the waters sailed by SIBs are teeming with them. They drill holes in your hull, wait for your boat to sink, and then eat you. Some of them are:

• Lack of continuous attention to software quality.
• Lack of supporting (project management) and facilitating (business analysis) skills on the software team.
• Ineffective business involvement in the software process.

They are allowed to exist because no one recognizes the damage they can cause, due to mistaken beliefs about software development processes, constraints, and economics.
The mistaken beliefs about software are most often extrapolations of what the executives know about managing other business assets – people, finances, physical plant, intellectual property, external relationships, or even (and most insidiously), IT infrastructure! When things are going badly, people seem to go one of two ways—try harder at what’s worked in the past, or panic and question everything.
Now What?
In order to float your boat again, you’re going to have to change your ways:

1. Adopt accurate beliefs about software
2. Get rid of the existing auger sharks
3. Fix the holes
4. Pump or bail out the water

It’s important that you a) start all four activities immediately, b) continue them all until your vessel is sound and dry, c) apply added energy to that which will keep you from sinking completely, today, and d) not forget your core business.
Adopting accurate beliefs
Finding a source of accurate beliefs is hard. Many mistaken beliefs are still widely held and actively promoted, even though they were refuted a long time ago. Adopting accurate beliefs is harder. Executives, especially previously successful ones, often respond to a lack of results by trying harder, when what they need to do is try different. Programmers are also prone to take strong ideological stands, and they may not be all that familiar with or interested in the larger context, technical as well as business.
Team up with your programmers to identify and replace mistaken beliefs, learning from and leaning on the same trusted sources. Just doing this will start plugging the hole of mistrust and miscommunication.
Get rid of the existing auger sharks
Changing behaviors is also hard, especially when you’re under pressure. Increasing attention to software quality, and involving the business people in the software work, will take time and feel fruitless at first. And adding skills to your team will cost you time and/or money and will disrupt things further. You will have to work these changes in gradually.
Plugging the holes
The hardest hole to close will be technical debt. Think of it as paying off a loan. The interest payments are time spent repairing software that breaks every time anyone touches it. Reducing the principal means diverting some of your software-development capability away from changes and enhancements that directly yield value to your business, to cleaning up what you already have.
Bailing out the water
You must never forget that you are a software-intensive business and not a software company, and keep advancing your core business as best as you are able to, even as you’re refloating the boat. It’s tempting to manage the software situation as a crisis, and look forward to things getting back to normal. You need to be establishing a new normal, or otherwise you will wind up right back where you started, thigh-deep in water.