The really hard question Pt 1
OK, if we’re going to go about delivering the impossible, we need to manage contradictions, and the first step of that process is:
identify the contradictions.
And identifying 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. But as I might have mentioned in a previous post, if you don’t managed the contradictions in your project, they will manage you, and by that, I mean:
contradictions that you don’t manage will utterly destroy you.
As I mentioned, again, in a previous post, 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.
Once we’ve identified the contradictions, we need to manage them.
But then, the really hard question is:
how to we manage the contradictions that we find?
Trade-offs
Some contradictions are trade-offs. And there a couple of things about trade-offs. Firstly, even if clients can’t acknowledge this, it should be acknowledged that things are trade-offs.
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 pit stop 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 absolutes.
Software should be totally secure.
Or:
Software development should be as fast as possible.
So here are some steps to dealing with contradictions which are trade-offs.
Tech debt is embarrassing to developers. It’s something they’ve done that hasn’t been done in the best way possible.
Anything other than “perfect” security is embarrassing and potentially threatening to clients.
One way that I have found that has worked is to bundle the management 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 go wrong.
And it has a software development corollary:
Anything that is essential to the writing of software might not be available to 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 saying that was that we didn’t have very good internet 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.
Originally published at https://mumbly.co.uk.
