Sebastian's blog

It depends … too much

tl;dr

This is a rant about indecisiveness.

Let's go!

We all know the software architect's (or engineer's) favorite answer is, ‘It depends.’ And there are good reasons for this. It really all depends – on so many things. When coming up with solutions to problems, there are many factors to consider, so any blanket statement, given without knowing the context, is likely to be wrong. Sometimes horribly so. Every software engineer (and architect) should periodically remind themselves that the key to good decisions is considering the context, dealing with conflicting forces, and carefully weighing benefits and risks. The best answer always depends. It is so. Really. And yet… I sometimes feel we have taken it too far.

While hammering this lesson in (and it is an important lesson!), we have somehow elevated ‘It depends’ to dogma, repeat it like a mantra, have come to the unconditional belief that everything always depends, and, crucially, that knowing the answer is impossible. Because how could it be possible? If we accept that there are unknowns – known unknowns and even unknown unknowns – and that ‘it depends’^[1], how can we be certain that any solution will be right? We can't. Not really. So we hedge. ‘It depends’, we cry, and somewhat smugly retreat to the position of ‘not knowing.’ This is a safe position because we can delay by asking for more context. Which is fine, I guess, if time is not an issue.

But … wait a moment! All of my architectural work is done in the context of a particular organization, most of it in the context of a particular team. I – and the collegues I work with – already know the context. An external consultant might get away with ‘it depends’ as an answer to an architecture question, but we won't. I won't let us. Here are some real conversations I have had with team mates in the last year:

‘It depends on how many API consumers we have.’ – ‘We have 5.’

‘We don't know if team A is using this function.’ – ‘They are. We had a meeting about it, and we can see it in the logs.’

‘But if team B wants to change this in the future!’ – ‘They didn't manage to change the last 3 things they wanted to change in their legacy system. They could't if they wanted to. So they won't.’

Yes, in general, it might depend, but in our particular case, this uncertainty does not exist because we already have the answers. Sometimes, it seems to me we have cultivated the attitude of ‘not knowing’ to a point where anyone purporting to have an answer is immediately suspect.

And another thing: dev teams don't have a monopoly on uncertainty. Everything is uncertain. But we usually don't qualify each and every answer we give. Here are some conversations I didn't have in the last year:

‘Will you be home for dinner?’ – ‘It depends. If I am run over by a bus on my way home, I might not be.’

‘Can we watch the show later?’ – ‘It depends. It might be difficult if the monitor blows up.’

‘Can you make it to the meeting?’ – ‘It depends. If the S-Bahn is punctual – no problem.’

OK, I'll grant you the last one. You get my point, however. At some point, we should be certain enough that we no longer need to qualify our statements. Yes, team B might still want – and manage – to change something, just as I might be run over by a bus. And if they do, we will have to change our plans, too. But this is true in any case. We have to work with what we know. This is not to say we shouldn't make an effort to find out things we don't know or to question our assumptions. We should. But at a certain point there are diminishing returns to further inquiry and questioning our knowledge. A point, at which ‘it depends’ stops being useful. A point where we need to decide.

Then we must do so, being fully aware that later on it may turn out we were wrong after all. But we cannot know that because … it depends.