Skip to main content

It depends

A few months ago I wrote a post I Don’t Know. It was a post that explained why being honest about things you don’t know is important, as it builds trust amongst team members. I also explained why saying you don’t know something and following it up with a desire to actually take action, in order to gain that knowledge, is important. Today, I will talk about the words “it depends”.

Dependency Diagram for a recurrent artificial neural network. Source: Wikimedia Commons

Consultants are accused of overusing this phrase and rightly so. You see, if someone is asked a question and the response is “it depends”. Neither is the question answered nor is the information necessary to answer the question supplied, or a request for more information communicated.

When being consulted on a certain subject matter there is the reasonable expectation that the consultation will result in an answer or be directed to an answer. As such, I have been trying to follow up the words “it depends” with context on what the dependencies are. You see, a lot of the time I’m not lying when I say “it depends”. To stop at "it depends" though is not helpful, what is more helpful is following up this phrase with a request for context or a statement on dependencies. For example:

Question: “Should we run UI tests before merge into master”
Answer: “It depends, how long do the tests take to run?”

Question: “Is it worth having failover into another region”
Answer: “It depends, what is the consequence of downtime?”

What I found after months of actively follow up the words "it depends", is that at times, I’ve completely eliminated the requirement to say “it depends” all together. Let’s try the above examples again:

Question: “Should we run UI tests before merge into master”
Answer: “How long do the tests take to run? If they don’t take too long it may be a good idea. We can try it and see whether the slight increase in feedback time annoys developers”

Question: “Is it worth having failover into another region”
Answer: “What is the consequence of downtime? From my understanding we are a phone call away from all users of the system. Taking this into consideration in addition to our small user base, it may be a bit of an overkill to have failover.”

The above examples try to provide direction from the request of consultation. In many cases though, it is up to the person who's consulted me to eventually make the decision. I can only give my opinion, the facts as I see them, and seek clarifications on dependencies.

If someone has asked me a question it means they value my opinion. For me to simply respond back with “it depends” without actually providing clarification on those dependencies would not actually achieve anything. It’s OK to not be able to answer a question straight away and ask for further clarification, it's even OK to say you don't know Either way, not leaving the question hanging is the key to actually getting it answered.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?