Software engineering and product development are different from other streams of business (manufacturing, for instance). Things are more predictable in manufacturing, specifically in the execution phase. But it is no so at any stage in product development, where you get to know the next challenge only once you solve the current one.
What has this to do with “Google time”? Many of us might be aware that employers give some time every week to their employees to work on anything they like. Most of the employees during this time spend time on their own learning or working on their own side projects. Many of the in-house tools and even products are born out of this activity.
But the main intention behind giving such “do-Whatever-you-Wanna-do” time to the employees in my opinion is not to churn out such side projects. The main reason and science of this lies in the “Queuing theory”. Less.works explain in great detail how the utilization levels affect the flow of value through the system. I will attempt to summarize it and put it in a context.
Imagine you have a highway and the vehicles are moving through with ease. Let’s say the traffic increases, vehicles gradually start taking more time to get through.
Each new vehicle coming on the highway gets added to the “Queue” and the time to get that vehicle through then is, can you guess?? As may predict it is linear, but it is not. It grows exponentially, until a certain point when you cant get anything out of the system, which means the response time goes to “Infinity” (mathematically). Such a curve is called M/M/1/∞ curve.
So the thumb rule is, when your size of inputs to the queue are random and when the time taken to process each input is random, then the system response can never be linear, it follows the curve we just described. This theory applies to many scenarios including server utilization for production systems and…… yes, you guessed it right, it applies to a developer’s day to day life as well.
How? as we know that in software development, we can never accurately predict the time it will take us to complete a task. We can only guess based on our experience. Each task gets done one after the other, in variable amount of time.
So let’s say that you, as a developer, is given a task each day of the week. There are 5 tasks you need to complete in this week.
On Monday, you are excited and start working on task A. However, it takes some more time in the end to test and deploy the functionality. You therefore, utilize some of the time on Tuesday to finish task A.
But wait, you already need to complete task B by Tuesday day end. Without wasting any time you get to work on Task B. Task B turns out to be tough one to crack, after you start working on it, you realize that you need some more technical help within the team to proceed. It turns out that you finish Task B on Wednesday.
On Thursday, you already have 2 tasks (C and D) in your plate. You start to feel the pressure now, and you are already thinking about multiple things at a time. On Thursday, your manager calls for a team meeting to discuss teams performance in last quarter, you lose half a day in the meeting (not to mention the context switch that comes along with it). You work on Task C, by sitting late in office and try to complete it.
When you arrive on Friday, you already have 3 tasks assigned to you which you need to complete by EOD. You realize that it is unrealistic for you to achieve it. This is exactly the breaking point, mentioned in the “Queuing theory”. Beyond this point of time, no matter how many tasks you keeping adding to “Your Queue”, they will take (mathematically) infinite amount of time to process.
I’m sure this has happened with most of us at some point of time in our careers. Linearity calculations do not work in software development. So how do we solve this problem? Well, that is precisely why good companies give their employees, some time to take control of their queues. Moving fast, compromises quality and increases technical debt. Most of the time, good employee’s, will utilize this Google time to either finish their pending work or to reduce the technical debt they introduced, when they had to finish things quickly.
There may be times when developers finish work quickly than estimated and may spend this time, learning or work on something else. Either way, it benefits the company, but as we just saw, these are the extra benefits. The main intention from management’s perspective is to induce the “Flow”, so that value get’s out of the system at a consistent pace.
