Starting up again
It’s been a difficult couple of months since I last posted. My team has been hard at working finishing up a major release for our software. Luckily it all went smoothly and we are going to be winding down for the next month while we plan out the next stage of our development. Everyone develops differently at different companies but I feel that in general development crunch time is something that happens to everyone.
Crunch time is the time before a deadline where the entire team works long hours trying to get every last bug fixed and jam as much as possible into the release so that promised features make it in time. No matter how well planned out you make a project it seems to always end up with some form of crunch time. I always wonder why that is why are we unable to finish projects early. Even this post was meant to go out earlier but ended up being finished way later.
I am sure there is some good science out there related to planning and estimation and why we are pre dispositioned to procrastinate. I feel that in general my team’s problems lie in failure the estimate. At my current job we work on multiple contracts at once which leads to conflicts and a lot of context switching. This alone can lead to pretty poor estimating skills but I think on top of that we just fail to adequately understand our own skills.
In order to properly estimate you have to first understand your own ability/skills. Usually a task we think will be easy, will end up being much more difficult. To combat this we always pad our estimates, which is the practice of taking our original estimate and adding like 20% or some arbitrary number to it. This should protect us from failure to estimate but it does not. I think the reason at least with my team is because our original estimate is not what we truly believe it will take.
The reason why our original estimate is wrong is because we are trying to satisfy the customer who has a specific budget. In contract work which my team plays a part in we have a project manager that has a very specific amount of time and money. As engineers we are left with trying to satisfy the demands of the project manager while maintaining the budget. If you have a set of requirements as well then you are left with a tough decision. That decision is what to cut.
Ultimately requirements can’t be cut in order to make sure we satisfy the contract and the customer’s needs. We can’t add more engineers because we have a stiff budget. We can’t expand the timeline really because we are a small cog in a larger schedule. So ultimately we cut things like planning, testing, documentation, clean code, and other quality of life stuff.
This ultimately creates a difficult situation where you estimates are not truly what they should be. Adding 20% to an underestimated task may not get it to the right number. Plus removing the planning and research phase makes it harder to get your tasks done and ultimately increases the over time. All this together creates crunch time.
When crunch time hits your team hard it can lead to a lot of problems like burnout, apathy, sloppy code, and many other issues. It’s important to take time off when you can to regroup and reevaluate what you are doing. If all you do is work then you will end up in a bad situation and can severely impact your ability. Taking breaks is always important and we should all remember that what we do is hard work and can affect us more than we believe.
With that said I am going to queue up a series of posts about my next couple of projects that I will be working on. They include a electron angular 2 cli solution. Electron splash screens and a Nuget net standard library to interface with the nuget v2 OData api. While those posts are getting published I will be on vacation in Yosemite National Park and when I get back I will try to post some pictures from my trip.