Developer Myth: Work Expands To Fill The Time Available
Over my career, I've worked with engineering managers who've taken an unfortunate view of the engineers that they managed. A point of hot contention between these two groups was always the estimation of deadlines. Engineers would estimate that a task should take X days; managers argued that the same task should take half as much time. Occasionally a manager would use an over-simplification of Parkinson's Law to justify the tighter deadline - that work expands to fill the time available. This concept has never sat right with me - not for small engineering teams. I don't find this thinking to be true for myself or any of the people that I work with. In my mind, this is a developer myth.
| |
|
|
||
| |
 |
|
||
| |
|
|
For me and the people that I've personally worked with, shipping functional code to production is a point of pride. The more often we can ship code - the more tasks that we complete - the better we tend feel about ourselves. Software developers are craftsman; and, the code that we produce is generally the best possible code we can produce at that time. Every line is the product of an evolutionary process - an expression of years of trial and error; of learning from our mistakes; of failing hard and getting back up on the horse, vowing to do better next time. No developer that I know wants work to take longer than it aught to.
Now, that's not to say that work is always delivered on time. Far from it - life isn't that simple. Not only are developers horrible at estimating task complexity, often underestimating the time required; but, it is almost impossible for an engineer to work in isolation. Emergencies, bug fixes, teamwork, and competing priorities are a constant in the life of an engineer. Taking these two facts into account, it's almost impossible for any task to be completed on time.
Helmuth von Moltke the Elder: No plan survives contact with the enemy.
At this moment, I'm behind on one of my major 2017-Q1 goals. I was hoping to have a payment processing upgrade done by the end of January. But, it will likely take a few weeks into February. When I look at why my timeline is slipping, it's not all that surprising:
- Scope Creep - The goal itself has gained some size, evolving as our understanding of the goal evolves.
- Emergencies - I've been involved in several emergencies and the precipitated resolution tasks.
- Competing High Priorities - There's simply other high-priority tasks that need attention and I do my best to divide my time appropriately.
- Competing Low Priorities - Sometimes, I take a break to solve a few smaller tasks (decisions I make as an autonomous human being).
- Team Work - I'm on a team and I often take time to both give help and to receive help from the awesome people on my team. Being part of a team doesn't stop simply because I have some deadlines.
- Underestimation - Like I said, engineers are bad at estimating task effort and I am not immune to this. Individual tasks are taking longer than I had expected; and, I didn't account for things like backwards compatibility strategies and the complexity of syncing back-end and front-end code during rolling deployments.
To be sure, some of the slippage is due to poor time management, no doubt. But, for the most part, I think it's just the reality of working in a messy, highly dynamic world. And yet, despite that rationalization, I still feel bad about it. Part of me still feels like I've done something wrong. I'm sure part of this response is due to my personality; but, I'm also sure that part of this response is due to years of having unrealistic deadlines held over my head.
Deadlines can serve as a point of negation between an engineer and his or her manager. If you need a shorter deadline, you can decrease the scope of the task. Unfortunately, it almost never works out this way - managers will often tighten deadlines without sacrificing or adjusting the scope at all. They do this because they believe that work expands to fill the time available. But, in my experience, this is not true. And, I fear, treating deadlines in this manner does nothing but set a team up for failure.
Reader Comments
So much yes to this. To me, that is a key point in a good leader of a dev team, to understand this concept. Some of the best leads or managers I've worked under were former devs and understood the realities of development.
Things are dynamic, and there are so many forces pulling and pushing. I pride making the best that I can. One thing I like at the heart of agile philosophy, as I see it, is delivering a quality product. Small, iterative sprints yielding quality code. I once had a lead say that "There are three things to pick from: quality, time, and scope. You can pick two." In my mind, quality is always the first default choice, so you can either pick the scope to be fixed or the time. Yes, obviously, you have the goal of both, but as you wrote, things happen and it's not always realistic (sometimes even an arbitrary date).
+1
Having worked (more often than not) under unrealistic or unachievable deadlines, I sometimes question my efficiency. After examining the facts, I usually determine the big gap in estimations are due to a combination of 1) misalignment of interests b/n the craftsmen (devs) and the salesman (manager), and 2) a lack of empathy b/n them.
I actually keep Bill Curtis's SE radio interview (link below) on my phone whenever I need reality check. I try to keep aggressive management practices from influencing my estimates, but it can be difficult and usually is.
http://www.se-radio.net/2016/07/se-radio-episode-262-software-quality-with-bill-curtis/
@John,
I think small iterative sprints are totally the way to go. When I look at a project, I try to think about how I can release it in parts. Not necessarily an "MVP" kind of approach, but rather which parts can be released quasi independently... and then actually do that - release them independently.
I remember having a conversation not so long ago where a team lead was running something by me - a rather large front-end and back-end project. After listening / looking at what he was saying, I suggested that he could probably just make like 90% of the front-end changes first, in a relatively short amount of time. Then, worry about changing the back-end and "finishing" the front-end to apply that last 10% of the functionality. While he liked the idea, he told me that it was an "all or nothing" approach.
I just don't understand the strategy behind some of these things.
@LambdaSauce,
Thanks for the link, I'll have to check it out.
I was once working on a project that I estimated should take 3 months. I as told that I had 1.5 months to complete. A week into the project, I knew without a doubt it would be done in time. I tried to tell the powers-that-be about this - that expectations should be "managed". No one wanted to listen. So, I wrote the 1.5 month due-date on a sticky paper and left it on my monitor. Then, when the 1.5 months passed, and the 3 months passed... and it was finally done in 6-months, every day, I would come in and sit down and stare at that sticky paper and remember how crazy it was.
@Ben,
When starting something big like that, I like the same approach. I usually look at use cases and feature sets and see what I can break into small releasable parts as well, even if in releasing to public it is seen as "all or nothing". When you're in that boat, at least it can work well for internal demos, showing the completed sections. It just feels good when you can say that you can take a small part beginning to end and say "see that over there? that's good to go". Then your unit tests are your safeguard against unintended "fixes".
Something like that if you can do 90% of the UI changes first, why wouldn't you? Being that the UI is what the user sees largely as the "app", that can be a huge boost improving and making those changes first. And really, if we're talking perception, while everything might fit into on "release" if you do 90% of the UI, give it to the user, then do the 10%, you really are getting 2 updates to the user for the price of one. And it gives you extra time to iterate on that 90% if something doesn't end up working out as you might have expected.
@John,
So much this:
> And it gives you extra time to iterate on that 90% if something doesn't
> end up working out as you might have expected.
... which tends to be the case on larger projects, in my experience :D