The crunch-phase of a project, in which a team works frantically in order to finish a product until a deadline, can be an excruciating time for all the people involved. During my time as software developer, I had my fair share of crunshing, but nevertheless decided to initialize a crunsh in a completely different environment. In this post, I want to present the findings and conclusions of this (mad) experiment as reference for people that have to or will have to crunch, and want to make the best out of the experience.
In order to finish the first test release of our webcomic reader Comicol, we decided to crunch. For us, this meant meeting up and spending two days working in close confinement.
To be clear, we had no hard deadline. What drove us was high motivation and the desire to get things done, not external pressure. Still, I am sure that what we’ve experienced translated to other forms of crunshing as well.
The first and most important finding: Take breaks! Preferably, take breaks together. Breaks are great stress relievers as well as a convenient way of letting the team know what you have achieved and what bothers you. Another imporant aspect of breaks are distractions. A lack of such results in a narrowminded approach of problem-solving that hinders progress much worse than any reasonable amount of breaks ever could.
The importance of this becomes obvious as soon as you’ve experienced a conflict of different modes of thinking elicited in a very interesting way by an exercise presented in Betty Edward’s “Learn to Draw: Drawing on the Right Side of the Brain.”. It requires the reader to sketch two symmetrical parts of an optical illusion while talking about what is drawn during the second iteration. What ensues is a conflict of thought that can feel paralyzing for a moment, because drawing and talking engages two different modes of our brain, as they are abstracted in the aforementioned book.
Taking breaks allows our creative side to come up with cleaner or more intuitive solutions. Even without further scientific background, I am sure that everyone has experienced the same phenomenon before. Think of the times when you suddenly had ideas in the shower, while exercising, or in other unexpected places.
If you can’t establish an environment or the self-discipline to take regular breaks, time management techniques like Pomodoro can help.
Listening to music while working is a controversial matter. While I personally like to listen to ambient music while working, I think that more engaging music can have far superior effects when working in a group. For us, listening to Hans Zimmer’s soundtrack of Inception while merging an important branch was hilarious. Similarly, we listened to various forms of jazz, swing, alternative and other musical categories as appropriate to our mood and work activity. This practice not only kept us going, but made crunshing a fun experience while we pushed ourselves to our limits.
Stick to your code quality standards. We got carried away by our high motivation and the prospect of fast progress and, as a result, produced a qualitatively much inferior product than we started out with. Dividing the work into more diverse tasks that get published for reviewing earlier helps to make sure that no extra work ensues after the crunsh. This feature breakdown is especially helpful to mitigate the threat of believing that multiple chunks of progress belong to a single task of a certain feature. That misconception leads to extraordinarily large review requests and delays other dependent features.
All the previous topics propose actions that delay, decelerate or divide the pure coding process as compensation for the positive effects mentioned. As a result, the crunsh itself has to be scheduled accordingly. Crunshing early with adapted planned features will help in this regard.
Crunshing should not be taken lightly. It is far more than working a lot on a project. Efficient crunshing takes careful planning, a fitting work environment and a certain mindset of the participants. Keeping the mood up while not getting sucked into working non-stop are the key factors for success. I hope that this post will help you to design your next crunsh to be as efficient and fun as it should be, while avoiding the problems that we’ve encountered.
Lukas is Innovaptor's jack of all trades. By honing a wide variety of skills, he aspires to find the perfect solution for Innovaptor's customers. He has already worked as C++ Software Engineer, Java Software Engineer, Systems Administrator, external Lecturer and Backend Developer and uses his experience to create exceptional software. In studying Software Engineering & Internet Computing at Vienna University of Technology, Lukas further pursues his passion of lifelong learning.