Almost every successful startup company reaches a stage where the “quick and dirty” way of coding becomes a quality liability and makes it difficult for the company to continue to grow and develop. At MyHeritage we encountered this issue, but because we were already running a successful website and supporting a huge user base of millions, we couldn’t just stop what we were doing and “refactor” the required code. Doing a quality change in parallel with our company’s growth in product and complexity was an extreme challenge that required the right state of mind and the right set of people.
This, then, is the story of how MyHeritage created a real quality change in an extreme environment.
A couple of days after I arrived at the company, I got some courage and decided to code something small by myself. My hands were a bit shaky, but I was thinking to myself, “What could possibly go wrong? If I really make a mess, the unit and integration tests will detect it.”
After I wrote a small piece of code, I planned to add a test and asked for a colleague’s help. “Unit what?” he answered. “Just open the website, browse to the page your code affects and see what it looks like there. Worst case, QA will let you know if it doesn’t work.”
The team understood very quickly that this is not the way to go, and that we needed to do some rethinking about some of our engineering practices.
The first step: Coding standards
The first thing we agreed to start with was adopting coding standards to be used by all developers. So with the help of our CTO and feedback from all developers we decided on the coding standards for MyHeritage that included in addition guidelines for error handling and the way to deal with legacy code.
Like any beginning, this one was not easy. In one code review after another, developers commented to each other about coding standards and asked people why they have warnings in their code. But after a while people have forgotten they used to code in a different manner.
Right after presenting the coding standards to R&D, we started working on having unit testing guidelines and an education plan. Beyond the obvious benefits of unit testing, these tests contribute a lot to code quality and keep classes coherent with well-defined roles and responsibilities.