Skip to content

How To Fixit: Keep it Simple. Take a Day. Make it Fun.

Published

June 2017

By

Ann Jaskiw

How To Fixit: Keep it Simple. Take a Day. Make it Fun.

Though the term technical debt often has a negative connotation, it is a common and often healthy side effect of rapid software development. Just as taking on a mortgage can be a well-calculated decision for an informed homeowner, amassing some technical debt to get a product out the door can be necessary. And, just as the buyer pays off that loan over time while thriving in a new home, a team of engineers tackles technical debt to maintain a viable product.

At Flatiron, we are by no means immune to technical debt accrual and have become increasingly cognizant of its impact. About a year ago, as an experiment, our engineering team allocated a single day to chipping away at our technical debt. We found it to be a useful experience, and several iterations later, we have a stronger understanding of how to organize a "Fixit" that is both productive and fun. There are several key components:

Keep it Simple

Fixits only last a day, so simple instructions are instrumental to success. A good fixit has guidelines and a well-defined scope. The first step is to set a goal with clear directions that allows participants some liberty to choose what they work on.

A few months ago, we realized being on-call was becoming increasingly difficult as the organization grew and the architecture of our systems evolved. We opted to address the problem with a Fixit. Everyone on our team participates in the on-call rotation so buy-in was natural.

Superficially, our goal appeared to be "fix on-call", but this objective was overly nebulous. Thus, rather than broadly asserting the obvious "we should fix on-call", we narrowed the scope to improving our wiki pages. That said, we did not assign engineers to specific pages, but rather created a shared document in which people posted what portion of our wiki they were mending. This approach allowed people to choose what they worked on while avoiding duplication of effort.

Take a Day

Every quarter, we try to block off one or two Fridays and designate them as team Fixit days. This ensures engineers have enough bandwidth to participate if they so choose, and an organizer has sufficient time to set things up. Fridays are designated "no meeting" days at Flatiron, so they are good candidates for our Fixit days.

Make it Fun

Fixits are objectively more fun with a bit of competition. During our documentation Fixit, we requested submissions for egregiously out of date and thus hilarious references in our wiki pages, then voted on our favorite ones. It ended up being a great way to see how our systems have evolved, and we as an engineering team along with them. Processes that once took half a dozen steps and manual intervention from different parties had become fully automated - a full wiki page replaced by a single command!

Gamification opens the door for awards. When it comes to prizes, we tend to opt for eternal fame and glory in the form of small and inexpensive objects that double as desk ornaments.

A recent Fixit award in feline plush form

A Fixit is not…

A hackathon

While Fixit and hackathon tasks may overlap, it is important to distinguish the two. At Flatiron, we hold two-day hackathons every quarter. All employees, not just engineers, are encouraged to work on a project they would not normally have time to do. Fix something old, build something new, make something better. Move quickly and build stuff. In essence, any task suitable for a Fixit is an option for a hackathon, but not the other way around.

A project that requires significant planning

A group of engineers, when well coordinated, can build something amazing in a short amount of time. However, an architectural overhaul or major code refactor falls into the realm of major technical debt and should be prioritized as such. Timeboxing Fixits to a day prevents taking on a leviathan task.

Mandatory

Participation in a Fixit should be completely voluntary. We opt to hold a kickoff session and an awards presentation that is open to everyone, but engineers are free to define their own priorities. With this approach, we have had high participation in all of our Fixits.

Conclusion

Since our first Fixit in 2015, allotting a few days of each quarter to paying off our technical debt has evolved into an integral part of Flatiron engineering culture. We hope this guide will help you roll out Fixits (and the delightful prizes that come with them) to your own team. Happy fixing!

Share