FedEx Day in Development
If you happened to have read Tomas Rehor’s (Pipedrive Engineering Manager in Prague) post on LinkedIn in mid December about FedEx Day (FED), you may be wondering what it is about. In this post, I will try to explain the concept from a developer’s point of view and also what is required from you if you wanted to run this on your own. I have run several more-or-less successful FEDs already (in two different companies), and I am convinced that for some problems, it’s an exciting method to go with.
The origin of the FedEx day name is simple — you order some items and then get them delivered within the next 24 hours. The same idea can be applied to development as well; you choose a problem to solve and spend the following 24 hours trying to solve it. The concept was initially brought forth by Atlassian, which we then borrowed from.
At first, this idea might sound slightly ridiculous, but there are a few points to it which I believe make this a beneficial thing to try:
- focus: You can focus the whole day on solving one problem without any disturbance. No meetings, no support/colleague requests. No sleep, no personal life
- project: The concept allows you to work on tasks that, although important, might get ignored in the regular pipeline/backlog
- experiments: On all FEDs I took part in, we were trying something new, either bringing some new technology/library to the project or trying some new development pattern
- challenge: It is always a good thing to push the bar higher in a new direction
- team-bonding: Although non-traditional, it’s still a kind of team-building event
- fun: It can bring back memories of university hackathons from the times when we were younger.
Sure, all of the points above roughly relate to traditional in-house hackathons, and the ideas themselves are indeed similar, but in the table below there is a list of a couple of the biggest differences between the two.
Getting started
Obviously, some prerequisites first have to be met, and your company has to be open to these ideas. While it might be possible in smaller teams, it can get more complicated to run it in a bigger corporation.
You need to find a group of people who think the same way and are willing to try something new/crazy. They need to know what it will cost them and they need to see the benefits — there is no point if you need to persuade people.
It is essential to have support from your superior as they need to understand the value of the FED. It usually starts in the morning and spans over two workdays (the second day is when you go home to get some rest after finishing the initial FED). They have to be OK with your team not working on anything else during this time and you also need to get some space for preparations and landing.
Choosing the right project
The outcome of the work has to be valuable to your team/company and it’s a good idea to present and explain it to the rest of them. Be prepared to defend the work as there’s always a chance that someone may question the whole process.
From my experience, product managers/superiors are more open to letting you work on “cool” things with lower priorities during a FED. On one of my previous FEDs, we created a new, customizable and animated landing page to the product that at the end of the year, turned out to be one of the three hottest features of the whole version (released once a year)!
At the end of the FED, you should evaluate how well your team did so that you can understand if having an isolated project with a narrow scope is beneficial.
Try not to be too ambitious about the project you choose. Having a half-working prototype at the end of the FED that will then occupy the whole team’s energy for another week is definitely a bad idea and your management most likely won’t be happy either. The worst thing that will happen if you pick something too trivial is having a production-ready code at midnight and going home earlier.
We have failed a little in this aspect: we had decided to refactor one part of our UI that was in non-optional shape from the beginning of the project to reduce maintenance cost. However, at the end of the FED, we had to spend a few man-days to polish it up before it got to the production.
Preparation
You probably don’t want to spend the first several hours with planning and discussing how you want to implement the project. You might need input from designers or research, prepared copy or infrastructure, etc. This can be done beforehand in a potentially smaller group of people.
To enable parallelization between modules, it is a good idea to have well-defined boundaries and contracts. If you are designing both BE and FE, having defined endpoints and API models will come handy.
The better the preparation is, the more time you can spend on coding and making the project alive.
We are trying to adopt Domain-Driven Design in our projects, so we had a meeting where we have defined the domain together with our product designed and manager. We did technical preparations as well, described the API and data flow within the application, so everyone was on the same page.
Run
Schedule the most challenging work for the first two-thirds of the FED. After midnight the coding performance tends to go down, so this time is more suitable for testing and polishing rather than making architectural decisions.
Complete sync meetings often — depending on the size of the team, every two to three hours. When you are focused on only writing code, there is usually significant progress done quickly so you want to make sure everything is aligned.
Daylight is a great weapon for defeating drowsiness, if you are unsure about your ability to stay awake late, plan the FED closer to the summer.
As you will be spending 24 hours in the workplace, make sure you are comfortable (take slippers, change of clothes, etc.).
Landing
Even though you will probably write a lot of great code during the FED, it will rarely be ready to be merged into production right away. There will always be some work left, removing old code, writing more tests, etc. Make sure someone from the FED team will be able to spend an additional day or two on these.
As we are using Gitflow Workflow in Pipedrive, all code went into a feature branch that was later merged into production.
Share your work with the rest of the team and present your achievements. Organize a retrospective where you can highlight good things about the FED and what can be improved in a future run.
You can read the outcome here of a retrospective we recently did.
Usually, the first impression matters the most. If you try to run a FED and it turns out unsuccessful, you most likely won’t want to try it again. This would really be a pity, so don’t underestimate the preparation necessary.
The downside of a FED is that the evaluation of the outcome is difficult. Some features might be implemented more efficiently using the standard approach and some teams are just not able to work this way. Good preparation and retrospective will assist here.
I’m already looking forward to my next chance to complete another FED, and am glad I have found another company where it works to liven up and benefit the development process.
