Parkinson's Law and Software Development
As the leader of a software development agency, I’m in a unique position within my organization. As a software engineer myself, who sees both the business and development side of software engineering, I’m always looking for helpful concepts, paradigms, and principles. Also, and perhaps the most challenging, I lead the sales process at Project Ricochet. There are unique challenges in selling web development as a service: not only do many agencies compete for a given project, but also usually there is an upper limit to what clients will spend.
Over the years, I’ve homed in on two practices that allow web projects to succeed at less cost. The first is the Pareto Principle (see my blog on the topic). And the second is Parkinson’s Law, the topic of this blog.
In 1955, British author Cyril Northcote Parkinson observed that "Work expands so as to fill the time available for its completion." While he was referring to civil servants in bureaucracies, you will also find examples of this in your own life. Sleeping through your alarm clock, for example, can result in getting out the door for work in the morning in ten minutes rather than the one hour your routine usually requires.
This principle can also be applied to the software development process. More importantly, it can help deliver software projects more quickly, and at lower cost.
I believe that inefficiency is built into the web development process in three areas:
It’s so common that it’s almost a cliché: Marketing and Business teams and Engineering are like cats and dogs. Marketing and Business feel stifled and frustrated by the endless string of no’s and pushback. And Engineering teams bristle at requests because Business and Marketing refuse to think things through, and if they don’t fortify against the onslaught of requests, they’ll never finish anything despite working ridiculous hours running from one fire drill to another.
Here’s why this is dangerous: in order to build software that achieves its goal on time and on budget, teams need to communicate to zero in on the value trade-off implied with faster or less expensive alternatives (see my blog on the 80/20 principle).
Business: “We need X. When can it be done, and how much time will it take?”
Engineering: “We can de-prioritize your previous request and bump this to the top of the queue. It will take an additional week of work over the period of two weeks and will push out launch by a month. Do you want us to do it?”
Traditionally, that was where the discussion ended (with frustration on both sides). But Parkinson’s Law tells us that there is likely some subset of feature X that *could* be done while still hitting the launch date.
If teams can’t communicate honestly (or can’t communicate at all!), then you’ll have trouble yielding substantial results on this front. But if you can remove the organizational (and emotional/psychological) hurdles, you can find large blocks of waste in your development process. Just because someone asked for something doesn’t mean that they need it. And just because someone gave an estimate doesn’t mean that it *needs* to take that long. This isn’t always true, but often it is.
Organizations that can provide a feedback loop to developers regarding estimation accuracy can cultivate an environment where accuracy is incentivized and celebrated. In my experience, engineers start thinking in hours—and looking for opportunities to spend fewer hours—when they see how it affects the final result. Without this instrumentation, it’s easy to fall into the “it’ll get done when it gets done” mentality, and this can result in tremendous cost overruns.
Imagine a tremendously rich person who has never had to manage his finances or deal with any scarcity of money ever. When he plans a dinner party, money is no object, and the lobster, caviar, and expensive champagne result in an expensive (if fantastic!) evening.
I’d be willing to bet that when *you* plan a dinner party, you are more judicious with the budget. With effort, you can also have a great evening, and at substantially lower cost.
This is Parkinson’s Law in effect. The dinner will cost whatever budget you allocate.
Software engineers who are not held accountable to estimates, or to whom feedback comes only indirectly by way of “the launch date has been pushed out because we’re taking too long” updates, are a bit like the fabulously wealthy person. Without understanding how to leverage the pinch of scarcity, software simply costs more and takes longer to deliver.
In smart organizations, this is leveraged early and often yields tremendous savings over time. Otherwise, the wasteful organization does eventually feel the pinch (“If we don’t ship by Thursday, we can’t get our next round of funding and we’ll have to close our doors”) and can deliver. But by then, significant resources will have evaporated into the ether.
It’s tempting to see the software engineer as a lone hunter, traversing the Serengeti in search of his prey, waiting for the right moment to strike, then returning home a hero with his kill, feeding and nourishing the family for days.
But there are a few problems with this when it is translated to software development. First, complex problems are often significantly different than anything the engineer has ever encountered before. She can’t always rely on past experience to know how to solve the new problem. And as such, she can’t know what weapons and tools to bring with her. And in terms of resources, because the “hunting trip” can be indeterminately long, she doesn’t know how much food or water (or Mountain Dew) to bring.
In my experience, it is additional insight from the village (i.e. the rest of the engineering team). Software engineers (and really, teams in general) benefit from more open communication. The more complex the problems being tackled, the more liberally communication should be heaped on them. Approaches like Scrum build this into their model, and it can be challenging because, when things heat up, software engineers often want to spend *less* time communicating rather than more.
Sticking with these alone will yield cost savings over the life of any software project.
Parkinson’s Law isn’t like some “positive visualization” practice out of Rhonda Byrne’s book The Secret. Rather, it’s the manifestation of the fact that teams have almost infinite opportunities to affect outcomes of a group endeavor. Teams that are able to activate their “scarcity glasses” and see tough problems through its lenses can generate lots of time- and money-saving opportunities—and with intentionality, significant savings can be realized. Five hours here. 20 hours there. Oh, and there’s another 30 minutes!
Applying Parkinson’s Law is no silver bullet. Rather, it provides the opportunity for myriad “silver BBs” (did you ever have a BB gun as a kid?) that have small effects with any one shot, but a large impact in aggregate over time.
Try it. Let me know your experience. I’d love to hear from you.
Over the years, I’ve homed in on two practices that allow web projects to succeed at less cost. The first is the Pareto Principle (see my blog on the topic). And the second is Parkinson’s Law, the topic of this blog.
What is Parkinson’s Law?
In 1955, British author Cyril Northcote Parkinson observed that "Work expands so as to fill the time available for its completion." While he was referring to civil servants in bureaucracies, you will also find examples of this in your own life. Sleeping through your alarm clock, for example, can result in getting out the door for work in the morning in ten minutes rather than the one hour your routine usually requires.
This principle can also be applied to the software development process. More importantly, it can help deliver software projects more quickly, and at lower cost.
How is this possible?
I believe that inefficiency is built into the web development process in three areas:
- Isolation, siloing and poor communication between departments in an organization
- Lack of accountability and measurability in the software development process
- Infrequent opportunities to discuss novel approaches to challenging (or even mundane) problems
Isolation, siloing and poor communication between departments in an organization
It’s so common that it’s almost a cliché: Marketing and Business teams and Engineering are like cats and dogs. Marketing and Business feel stifled and frustrated by the endless string of no’s and pushback. And Engineering teams bristle at requests because Business and Marketing refuse to think things through, and if they don’t fortify against the onslaught of requests, they’ll never finish anything despite working ridiculous hours running from one fire drill to another.
Here’s why this is dangerous: in order to build software that achieves its goal on time and on budget, teams need to communicate to zero in on the value trade-off implied with faster or less expensive alternatives (see my blog on the 80/20 principle).
Traditional software development goes something like this:
Business: “We need X. When can it be done, and how much time will it take?”
Engineering: “We can de-prioritize your previous request and bump this to the top of the queue. It will take an additional week of work over the period of two weeks and will push out launch by a month. Do you want us to do it?”
Traditionally, that was where the discussion ended (with frustration on both sides). But Parkinson’s Law tells us that there is likely some subset of feature X that *could* be done while still hitting the launch date.
Using Parkinson’s Law insights, the Business team could respond like this:
- “Wow. If we still need to hit the deadline, is there some subset of feature X that could be done to achieve the business objectives so as not to delay launch?”
- “What if you had only one week rather than one month to do feature X? What would need to be true?”
If teams can’t communicate honestly (or can’t communicate at all!), then you’ll have trouble yielding substantial results on this front. But if you can remove the organizational (and emotional/psychological) hurdles, you can find large blocks of waste in your development process. Just because someone asked for something doesn’t mean that they need it. And just because someone gave an estimate doesn’t mean that it *needs* to take that long. This isn’t always true, but often it is.
Tight budget and even tighter deadline?
Check out our white paper on how to dramatically reduce costs on your next web project.
Lack of accountability and measurability in the software development process
Organizations that can provide a feedback loop to developers regarding estimation accuracy can cultivate an environment where accuracy is incentivized and celebrated. In my experience, engineers start thinking in hours—and looking for opportunities to spend fewer hours—when they see how it affects the final result. Without this instrumentation, it’s easy to fall into the “it’ll get done when it gets done” mentality, and this can result in tremendous cost overruns.
Imagine a tremendously rich person who has never had to manage his finances or deal with any scarcity of money ever. When he plans a dinner party, money is no object, and the lobster, caviar, and expensive champagne result in an expensive (if fantastic!) evening.
I’d be willing to bet that when *you* plan a dinner party, you are more judicious with the budget. With effort, you can also have a great evening, and at substantially lower cost.
This is Parkinson’s Law in effect. The dinner will cost whatever budget you allocate.
Software engineers who are not held accountable to estimates, or to whom feedback comes only indirectly by way of “the launch date has been pushed out because we’re taking too long” updates, are a bit like the fabulously wealthy person. Without understanding how to leverage the pinch of scarcity, software simply costs more and takes longer to deliver.
In smart organizations, this is leveraged early and often yields tremendous savings over time. Otherwise, the wasteful organization does eventually feel the pinch (“If we don’t ship by Thursday, we can’t get our next round of funding and we’ll have to close our doors”) and can deliver. But by then, significant resources will have evaporated into the ether.
Infrequent opportunities to discuss novel approaches to challenging (or even mundane) problems
It’s tempting to see the software engineer as a lone hunter, traversing the Serengeti in search of his prey, waiting for the right moment to strike, then returning home a hero with his kill, feeding and nourishing the family for days.
But there are a few problems with this when it is translated to software development. First, complex problems are often significantly different than anything the engineer has ever encountered before. She can’t always rely on past experience to know how to solve the new problem. And as such, she can’t know what weapons and tools to bring with her. And in terms of resources, because the “hunting trip” can be indeterminately long, she doesn’t know how much food or water (or Mountain Dew) to bring.
What is the answer?
In my experience, it is additional insight from the village (i.e. the rest of the engineering team). Software engineers (and really, teams in general) benefit from more open communication. The more complex the problems being tackled, the more liberally communication should be heaped on them. Approaches like Scrum build this into their model, and it can be challenging because, when things heat up, software engineers often want to spend *less* time communicating rather than more.
The following practices can yield creative approaches that allow arbitrary deadlines to be hit more frequently:
- Features above a certain level of complexity need to have an approach architected and approved by the team, or at least one other developer, ideally one with experience in that area.
- All features should be estimated at a feature level, and this estimate should be communicated to the Business team to allow them to either kill it (not worth it) or ask if it can be done in less time, which then kicks off a discussion around the *true* requirements (not just what was asked for) in a feature and what will take what to achieve.
- The moment a feature looks like it will take longer than expected, the team is made aware. It’s possible that other engineers can help unstick the problem with creative and less time-consuming approaches. It’s also possible that, with the updated estimate, the feature will get killed by Business, resulting in an overall time savings for the project.
Sticking with these alone will yield cost savings over the life of any software project.
Concluding thoughts about Parkinson’s Law
Parkinson’s Law isn’t like some “positive visualization” practice out of Rhonda Byrne’s book The Secret. Rather, it’s the manifestation of the fact that teams have almost infinite opportunities to affect outcomes of a group endeavor. Teams that are able to activate their “scarcity glasses” and see tough problems through its lenses can generate lots of time- and money-saving opportunities—and with intentionality, significant savings can be realized. Five hours here. 20 hours there. Oh, and there’s another 30 minutes!
Applying Parkinson’s Law is no silver bullet. Rather, it provides the opportunity for myriad “silver BBs” (did you ever have a BB gun as a kid?) that have small effects with any one shot, but a large impact in aggregate over time.
Try it. Let me know your experience. I’d love to hear from you.
Project Ricochet is a full-service digital agency specializing in Open Source.
Is there something we can help you or your team out with?
