Magic software dust or a bashed up Peugeot?

Creating a new software application… is that a glass is half-full or a glass is half-empty thing to you?

Does the thought of actually employing programmers fill you with joy or with dread?

Get it right and software technology is magical, get it right and software technology can change the world.

The browser you are reading these words with.

The phone in your pocket.

The GPS signal which will help you go… well… anywhere!

Some technology is absolutely magical. And some software development teams are absolutely magical. They really can get things done - “hyper productive” as they say. The Alpha AXP compiler team (“commitment management”) or the Quattro Pro development team are two of my favourite better known teams but I know a few others who nobody will ever hear of.

Done right software technology is like magic dust, a little bit of software sprinkled about in the right place, in the right way and Magic!

But many, probably most, never experience this. Such people don’t know how good it can be.

The science fiction author Iain M Banks novel Excession is about an “outside context problem” - a situation which is so far outside ones experience that one cannot even start to comprehend it.

For people who’ve never seen a great software team it can be hard to comprehend what software development can be. The closest these people ever get it is using Google Maps on their iPhone to find a beer.

This is sad, so sad, because it colours peoples view: software development is seen as an expensive painful exercise destined to disappoint.

Most teams aren’t hyper-productive, rather than working on a mission to change the world they remind me of an old Peugeot 206 advert - its on YouTube:

If you’ve not seen it it goes like this: Man looks at a picture of a beautiful Peugeot 206 car in a magazine. He looks at his old heap… and then sets about smashing his car up, driving it into a wall or two, then setting about it with a hammer while people laugh at him.

At the end of the advert his old car kind of resembles the Peugoet 206 - it helps if you squint.

Unfortunately an awful lot of software teams seem to be stuck in this model. They seem intent on smashing something into the shape they want rather than building it right.

Things can be better, so very much better.

Those who believe software is a painful glass-half-empty exercise make it worse for themselves:

• they try to constrain the builder by giving them a long elaborate “requirements” document
• they sign contracts to protect themselves, they specify what, when, how much and even how
• they drive price down because at least it if costs less the pain will be less which often means things end up in some cheap offshore location, out-of-sight, out-of-mind, out-of-control
• they compromise on quality left, right and centre
• quantity over quality is the mantra
• and they blame the coders: after all, everyone knows they are a bolshy bunch opinionated overpaid factory line workers (think Red Robbo) who always mess up

In making these assumptions, in protecting themselves from these beliefs the glass-is-half-empty people create a self-fulfilling prophecy. Each and every one of these actions will make the development process worse.

On the other side, those who see magic at work see software development as a glass-is-half-full thing and will work with the team who understand what is needed, they will be flexible on expectations and they will understand that high quality is faster and cheaper, they will see the development team are experts in the technology and how the technology can deliver benefit.

This too is a self-fulfilling prophecy. Treat the team as adults and they will respond as adults.

Its up to you: your beliefs will determine the result.

Surge or pivot? - notes on failure

Failure is good.

We learn from failure.

Failure is learning; the information content of a failure may be more than the information content of success.

Failure isn’t failure, it’s an opportunity to pivot.

Failure is capitalism’s Darwinian evolutionary mechanism to remove the less productive, the less relevant.

Fail fast, fail cheap, learn, try again.

Creative Destruction is the way capitalism remove legacy companies to create space for the new by allowing resources to be redeployed.

All true… well at least to some degree but lets not argue about that today.

The problem is: How do you know you’ve failed?

Or to put it another way: What does failure look like?

Or: When do you know its time to pivot?

Some failures are clear cut: customers don’t buy your product, or too few customers buy your product to allow you to stay in the market.

Our software does not perform as expected, it doesn’t process transactions fast enough, or a rocket blows up.

As engineers we like clear cut failure and success. We look for clear failures or at least clear bottlenecks if only because we are certain they exist. But that isn’t always the case. Sometimes there are no clear success or failure states. And sometimes we don’t call it a failure because we really think we can make it work.

Rationally the business plan or strategy should allow us to know what success loos like and what failure looks like. But what if the strategy is itself flawed?

Flawed strategy might be obvious to one person but hidden to another. When strategy is flawed it runs like a fault-line under everything that is being done. One clue is that lots of little failures keep appearing, seemingly unconnected perhaps but actually connected because they are originate in the fault line.

(Think if this like a stack corruption bug, you don’t normally know you’ve got stack corruption but you get apparently random failures. When you chase these failures they move. Back when I was still programming I knew I had stack corruption because the fault moved every time I thought I was getting close.)

Even when surrounded by failure we look to explain it away, we believe (hope?) we can fix it - after all, we are learning from those failures and we are trying to fix them aren’t we? And people like me (consultants!) asked to help you address your problems and fix your faults.

But when do you call time? When do you say things are irreparable? When do you stop trying?

To use a better know example: When is a war won? And when is it lost?

In 1945 Victory meant the Allies taking Berlin. Once Berlin was taken and the genocidal Government was disposed the war was over.

In 1991 Victory meant retaking Kuwait.

Afghanistan 2015? - some say success, the west was victorious! and some say it was a failure. Failure and success is not clear cut. For the generals and politicians its hard to walk away from a failured war, far better to find some success, get out and disown the subsequent failure - like the 1973-1975 gap in the fall of Vietnam.

Since failure is not clear, and especially since victory could be grasped out of the jaws of defeat by calling in more troops, more consultants, better consultants, more expensive consultants how do we know it is time to pivot?

When do we pivot and when do we surge?

And since failure is still failure, and no matter how much we call it a pivot or repeat that we learn from failure we still don’t like it; when, o when, do we call failure failure and when do we call it pivot?

And like Generals, Senior Managers can’t walk away from a failure, that would be career threatening. Far better to surge, get to something which looks like victory, get out and disown what happens next. (If you are spending your own money you have an incentive to get out quick, if you are spending someone elses money…).

When pivoting is unattractive, when pivoting means people loose jobs, when pivoting means executives have to explain to their board, when pivoting means shaman consultants no longer take their cut… why pivot when you can surge?

Surge - call for help.

When we are failing without a clear cut failure we see problem after problem and each one is explained away.

When do you declare failure and pivot?

Undercover Economist Tim Hartford had a good piece recently: “You don’t know when to quit”. The true grit, carry on trying idea doesn’t seem to stand up to analysis. Rather than persevering at something difficult a better strategy might be to try something else.

The more money that has been sunk into the initiate the greater the difficulty in pivoting - nobody likes sunk costs, why sink the money?

For a Silicon Valley start-up living on credit cards illusions are painful, there can be very little tolerance for failure, failure must result in a pivot or death.

But for a corporation, for an established vendor, a brand, a reputation; failure might mean they are simply not trying hard enough - and heaven knows some companies tie themselves in knots. Why not through more money at the problem? More people, more experts - surge!

And so we are back to Do it Right and then Do the Right Thing (blog) (and Do Things Right Thing and then Do the Right Thing presentation.)

For a software team capability means: delivering working software. If you can’t deliver working software you have a clear failure. But if you are delivering software slowly, so, slowly, how do you know? What software developer or product manager hasn’t wanted to deliver more faster?

If you lack the capability to iterate then you can’t deliver.

If you lack the capability to iterate you cannot build feedback loops.

If you can’t build feedback loops then you cannot validate your market or your product.

If you can’t validate product or market then your strategy is high risk.

If your strategy is high risk then you really need a high pay-off to justify it. But if you can’t iterate then its likely your costs are going to absorb far more of that pay-off.

You might be able to buy victory but the price will be so high it is worth asking: is it a victory you want? Is it a victory you can recognise?

Using cost of delay to determine schedule

“When does the business need it?” is far more important than “When will the developers have it ready?”. Business needs should drive schedules, engineers need to create solutions which fit within business schedules. That does not mean cutting corners, it does not mean shipping with bugs or technical debt. Its the art of the possible and its what engineers have always done.

One of the tenets of #NoProjects is that work should be guided by business benefit, better still value delivered.

That very quickly means that one need to start talking about opportunity cost of delay. As I’ve said before, I don’t think “cost of delay” is the best name for this idea, (I’d rather it was called something like “benefit foregone through delay” but cost of delay is the name we have.)

Once one starts discussing business value and how potential revenue changes over time it very quickly becomes clear that business need and value should drive the development schedule not developer estimates.

Rather than saying:

"How long will X take to build?"

We need to be saying:

"Given that there is M money to capture, in timeframe T, what can we build for that much money in that much time and have a respectable profit left?"

Time and money are inherently linked. Everyone gets that more time creates more costs but fewer people get that more time probably means less revenue.

To put this more succinctly

"How much of X can we build in time Y and how much of the total potential value M will that capture?"

Lets me do an example analysts to show how a cost of delay analysis - with value estimates - can be used to substitute effort estimates. So here goes, I'm putting on my economist hat... lets set up the scenario…

Image its Christmas 2016, at one of those family gathering you see Uncle George who works for a successful start-up. George says the back-end he has been working on is great and has a nice REST API. The start-up wants to grow an ecosystem and the company is about to open the API up to third party apps. The startup will pay a small "finders fee" from 1 February for the first few months to each of these third parties for each customer they bring in.

Back in the office on 2 January you make some calls and find everything Uncle George said is true. In fact the start-up is falling over himself to help you, they are desperate for apps.

You have an opportunity. And you have at least a four week head start on any competitor.

Some quick "what if" calculations tell you there is €10,000 a week to be made. But you also know that competitors will come into the market the finders fee will decline. As you have a 4 week head start you probably have 4 weeks from the start of February before your revenue starts to fall off.

Some more analysis and you conclude competitors will steal increasing chunks of your revenue, you think it will decline €1,000 a week after February. Thus you can draw the following graph:

The blue bars show the weekly revenue. The red line shows the total lifetime revenue - the lifetime being from the start of February to early May. What happens after May is uncertain so to play it safe you have assumed no revenue at all.

The red line is important - note: this chart uses two axis, the one on the left is for the blue bars, the one on the right for the red line. The red line shows the maximum revenue you could make, it forms an upper boundary.

It doesn't matter whether you release your product tomorrow or 31 January, there is no extra revenue to be made during January. As long as you have a product in the market on 1 February you can start to capture some value. If you have a fully functional product then you can capture €10,000 a week.

Yes the delivery date is important, earlier is better, but so is the amount of product. Since revenue declines from March onwards delivering something smaller sooner may well make more total revenue than delivering more later. Less (functionality) may well mean more (revenue).

As you can see, releasing a product anytime before the end of January will result in €85,000 of revenue in total. After this the later the product is released the less revenue if will make. Your deadline is not a binary event, it is an elastic range of options which each produce a different outcomes.

Time is money but money is both cost and revenue: The longer you spend developing your product the greater the costs, but more importantly if the product is not in the market by 1 February you are loosing revenue. The longer you go without a product the greater the costs and the lower the revenue.

This is a simple model, like any good economist I have confined my analysis. I have assumed "all other things being equal", specifically I have assumed other competitors do not spot the opportunity before 1 February; I have assumed your product could grab the entire market on day-1 without a ramp up time; I have also assumed that even launching in March, when there are other competitors in the market you can still grab sizeable market share an day-1.

These assumptions do not invalidate the model. These assumptions may all be relaxed with a more complex model but the basic message will still be the same.

This analysis does not use any effort estimates. It does use value estimates. So lets now consider effort.

In the first instance, armed with this analysis, you go to you development team and instead of saying:

"How long will it take to build this?"

You say

"Given this analysis, what can we build in the next four weeks which can capture some of this value?"

It is not a question of: "Can you build X?"" but "What can you build in this time for this much money?"

Lets suppose you and the team quickly envisage a product, a product that can be rolled out in stages, say 10% per week. Even the first 10% will be useful. Lets assume a perfect correlation between the percentage of product built and the revenue captured and lets add this to the model.

Notice in this model it is impossible to capture all the €85,000 potential revenue because the product cannot be ready in full on 1 February. If you wait until the product is 100% complete before releasing it will be mid-March and you will only make €28,000 in total. This contrasts with the €64,400 you could make by launching with reduced functionality earlier, i.e. launching a smaller incomplete product earlier allows the capture of €36,400 more.

As I said before I could relaxed some of my assumptions and enhance the model but I’m keeping this simple.

You can also play what if games, for example, what if you halted development at the half way point?

• If development halted at the beginning of February at 50% done
• and the product remained in use until May
• then it would generate €41,500 of revenue (64% of the total that could be made)

• This does not consider the savings in development costs. Perhaps more significantly, the same people would be available to work on something with greater returns.

After all the product only has an anticipated lifespan of three months. Once March arrives the product revenues are falling, why would continue to invest?

There are many directions you can take this analysis and I’m not denying the effort and cost estimates have a role to play in the complete analysis. However benefit estimates and cost of delay analysis can be performed without any effort estimates, when value analysis is available it can be used to inform the effort estimation process.

#NoProjects: an update

Several things have been happening in the #NoProjects world of late it seems fitting to record these things here.

1. As mentioned recently Evan Leybourn has created a NoProjects website. This is becoming a repository of various NoProjects things.
2. At the moment the NoProjects website is little more than a placeholder for a Slack community.
3. After months of saying “No I will not write a book” I’ve started to write a #NoProjects book. This is currently an early stage LeanPub endeavour. You can sign up for notification at the moment, I’m still drafting and getting my thoughts together. When it does start to appear it will be in the classic LeanPub form: small and growing.