The Really Hard Question

OK, if we're going to go about delivering the impossible, we need to manage contradictions, and the first step of that process is identifying the contradictions.

And identfiy the contradictions may not be that easy. And once you have identified them, many of the people around you may not thank you for identifying them.

As I mentioned, earlier. The very act of pointing out a contradiction can seem rude and impertinent to the client, but that absolutely does not mean that they shouldn't be breached in some way. And it certainly doesn't mean that they shouldn't be discussed more openly with the team.

And then, once we've identified the contradictions, we need to manage them.

But how do we manage them?

Trade offs

Some contradictions are trade-offs. And there a couple of things about tradeoffs. Firstly, even if clients can't acknowledge this, it should be acknowledged that things are tradeoffs.

For example: security. It's a trade off. The more secure a system is, the most expensive it is to build and the more difficult it is to use.

Another example: speed of software development. The faster that a team develops software, the harder it is to develop software. This is because of something called "technical debt" which I think of as all the tidying up and straightening out that you need to do as you progress with any process. Eventually, software will reach the point were it's impossible to add new features and it's impossible to maintain.

A macho metaphor for tech debt might be tyre management in Formula One racing. The faster you go, the worse the driving experience gets. Eventually you have to make a pitstop for new tyres.

Part of what makes these kinds of trade-offs so difficult is that in the mind of many, especially those who aren't familiar with software development, these things "shouldn't" be trade-offs, they should be asbolutes.

Software should be totally secure.

Sofware development should be as fast as possible.

So here are some steps to dealing with contradictions which are trade-offs.

Admit that there's a problem. This stuff can be ticklish and embarrassing.

Tech debt is embarrassing to developers. It's they've done that hasn't been done in the best way possible.

Anything other than "perfect" security is embarassing and potentially threatening to clients.

One way that I have found that has worked is to bundle the mangement of all of these trade-offs on a project into a "risk" meeting.

Every couple of weeks all of the risks that potentially affect a project are discussed.

Visualise the problem. How many issues, and of what severity do we have? Can we count these to provide some kind of score?
Identify some measures to improve the problem What can be done to address these risks?
Implement some of those measures Implement some of these measures.
Go back to stage 2.

Bricks without straw

Some contradictions aren't as subtle as trade-offs. Some contradictions are just crazy, and when you relate them, you can't quite believe that they ever happened.

But Murphy's law exists:

Anything that can go wrong, will got wrong.

And it has a software development corollary:

Anything that is essential to the writing of software might not be present in a situation where a team is asked to write software.

What sorts of things?

Computers: your team may be forbidden from using their own computers, but that doesn't mean that they will be provided with computers.
Access to the network: As one of my team members once memorably said "To make internetz you need internetz." But of course the reason that he was aying that was that we didn't have very good internetz at that point.
Access to development, test and deployment environments: this used to be a huge stumbling block, now of course, with the cloud this has got easier.
Access to the building.
The solution involved an interface with a system that doesn't exist.
The system involved testing against a system that the team cannot access.

How do you solve "Bricks without straw" contradictions?

We'll talk about that tomorrow.