Always be Coding

2 Jan, 2022

Do you have enough work in the sprint? #

It is not uncommon fro developers to hear this from their managers. It is a common pattern that every developer is expected to have coding task all the time.

This expectation comes from the top management, and flows downward for every team. A CXO expectes it from a VP, a VP expects it from a Group Manager, and so on, and ultimately a manager expects it from the developers.

As a consequence of this expectation, developers get stressed out. Developers feel that it is a red-flag if there is no development task in the pipeline. And, this is mainly because there is an expectation of working all the time.

This situation is perfect for a blame-game. For a developer – it was the manager’s job to create a clear work pipeline. For the manager – it was the developer’s responsibility to be proactive and ask the manager about the work pipeline.

So, whose fault is this?

Well, the problem is this ’expectation’. What could be the reasons that this expectation exists?

My hypothesis #

This expectation originates from the notion of Return on Investment (ROI). The company has invested in the employee and the company needs a return. However, till this point, I don’t see much problem. It is expected that if the company is investing in a developer, the developer must produce something.

The problem arises when we try to achieve this company’s goal with our own interpretation of developer’s input and produce. And, this interpretation is that – if a developer is coding, something is being produced, else nothing is being produced.

And, that is the problem.

You see that this interpretation considers code as the only input. It disregards everything else that a developer has to offer – pre-code, post-code, or parallel-to-code. This interpretation treats developers as machines.

Note that I am using the term ‘coding’ as a proxy for a development-task, which can mean tasks such as bug-investigation.

So, what’s really happening if the developer is not coding? The developer is thinking about the existing code. The developer is reading some existing code. The developer is analysing a technical decision. The developer is thinking about some team level processes. The developer is thinking about making the team better somehow.

If you think a bit further, you will realise that the interpretation considers only the produced-code as a return on investment.

In my observation, when we are thinking about the ROI for the company, we are always working out a mathematical equation that takes some inputs and produces some output. And, the work of the development team is just an input in this equation. Therefore, we all need a way to quantify this work. Maybe now you are remembering things such as story-points, estimation, sprint-planning, etc. So, yes, it’s all about the numbers in that equation.

But, it is hard to put a number on those free time that a developer has ended up taking. We cannot assign a number to it, because we struggle to predict its potential value. It is difficult to comprehend this notion of potential-value.

If we are really interesting in finding the value of this free time, we will have think about ROI over a period. We will have to invest time in working this model out. It’s not easy. Therefore, we take the easy way out and we assume that the ROI is zero for such a free time.

Bottom line, since we cannot find estimated value out of this free time, we cannot justify it to our managers, and our managers cannot justify it to their managers, and so on. Therefore, we need developers to code all the time, so that the perceived ROI can be generated.

Now, you are thinking #

What will happen to ROI-over-a-period if the developer leaves in less than 2 years?
What if a developer starts to take advantage, in the name of such free times?

On 1: Start fixing your internal problems.

On 2: Start re-evaluating your trust in your team members. Re-evaluate your fundamental values.

We are social beings. We like to live, work, build, and grow things together. This doesn’t happen if we start to treat each other like machines.