The hard quetion part 2 - bricks without straw

So, yesterday, we talked about how to deal with contradictions that are in fact trade-offs. Then we talked about what I would call "Bricks without straw" problems.

As I'm writing this now, I realise that when we were talking about the trade-off question I missed out THE biggie when it comes to trade-offs:

Scope vs time.

So I'm going to leave that for another day.

Today I'm going to talk about bricks without straw problems.

Where does the phrase "Bricks without straw" come from? It comes from the Bible. Pharoah, the nightmare of all clients, asks the Israelites to be make bricks without straw, which is apparently not a thing. But it's also important to understand that Pharoah is doing this to the Isralites as a punishment. Pharoah is deliberately sabotaging the Israelite's brick-making project.

In all the BWS (Bricks without straw) cases that I've experience in my career, I have to admit, that I've never seen a case where the client was deliberately trying to make the development team fail. Well. OK, there was this one time.

Let me take you back to the middle of that last decade.

I was working on a project for - let's say - Company A, the entire purpose of the project was to put some software on a live server. This was a government project for a government department, let's call them Department B, and it was in the days where there were very strict demarcations between different levels of security. For this reason, the only way that we could put software on this machine was to have one of our employees travel to the place where the machine was (in a different city 2 hrs away).

But it was a bit more complicated than that.

There was a separate company, Company C, providing the server. We were supposed to install our software on their server.

Our guy started his script. It failed.

He did some exploratory tests and found that there was a whole bunch of stuff already installed on this "clean" server. He asked the Company C guys if this really was a clean server as he'd been led to expect.

That's when the people from Company C, who'd supplied the server, started behaving really weirdly. They basically started saying "I can neither confirm nor deny" that there is anything already installed on the server that might be breaking your install scripts."

In the end the trip failed, the guy (he was going through a divorce and had terrible child-care problems and the last thing he needed was to be travelling four house) who had traveled to another city to install something on a server returned having failed in his mission.

What had happened?

It never became completely clear. But here's what we think happened.

Company C was contracted to provide Department B with servers for the project. Over the course of the project, the spec of the servers that Dept B needed for the project changed. Company C wanted more money. Dept B didn't want to pay. Dept B and Company C were in dispute.

Company C didn't want to end up in a situation where Department B didn't pay them at all, so while they were in dispute, they provided exactly the servers that they'd been contracted to provide in the original contract.

But here's the absolute cherry on the cake.

The original contract was secret.

So, if anyone at Company C had let our guy from Company A know that there was no chance his script was going to work, they would have breached the secrecy of the contract, and they weren't going to do that because it would give Department B ammunition.

But here's the blueberry on the cherry.

Department B knew this and didn't say anything.

Why? Why would Department B sabotage their own project?

If I'm honest, I'm not really sure. But exploring some answers to this question might be helpful in answering the question of how to deal with "Bricks without straw" contradictions.

Let's list some possible explanations of why Department B might end up sabotaging their own project.

Dept B are bad people (like the Pharoah) who just want to make everybody suffer.

I don't actually think this is likely. I actually think there were some none-too-good people in Dept B, but I don't think it was Dept B's intention to make the project fail.

Dept B knew that this was going to be a problem, but somehow hoped that Company A would managed to figure it out with company C.

I think this is a better explanation than #1, and there may have been some truth to it but I think this is more likely:

Dept B hadn't really thought it through. They knew that there was a dispute wiht Company C that they couldn't talk about, but they hadn't really thought through that this would stop the software being installed. They hadn't really thought that refusing to pay Company C for extra work that they had to do might result in Company behaving in a way that broke the project. The people we were dealing with in Dept B had neither the authority or nor the understanding to fix the contract issue. They were just hoping that by pressuring Company A to deliver, somehow the problem would get fixed.

And ultimately, at bottom, I think something like reason 3 is at the bottom of all "Bricks without straw" contradictions.

The client doesn't want to think about it, or doesn't understand it and hopes that the development team will solve the problem for him.

But there are some things that the development team just can't do on their own. Contract negotiations with other suppliers is one of those. But there are many others. There are also a lot of cases where trying to solve the problem without involvement of the client is a really bad idea.

Let's talk about that tomorrow.