Yikes, They Rewrote Evernote?
I couldn’t resist commenting on this interview with Evernote’s CEO about the project to rewrite Evernote.
First, disclaimer. I managed the Microsoft OneNote dev team from 2003 on for about a decade and am still a huge fan with much of my life recorded in OneNote. I’ve also written about OneNote internals in a number of posts and am friends with many on the team.
The interview referenced above describes the Evernote code base as a “monolith” that had grown “big and complex” and a “crufty, complex relic of a once-great app”.
I read those quotes through a couple different lenses. One lens is “Crowley’s Phases of Software Evolution” that I just made up. The pattern you often see in a software project is the first version gets built focused on delivering key functionality but the internals are a pile of crap. But it’s a small enough pile of crap with a small enough team that you can actually fix all the bugs and get the product delivered. Version 2 needs to get built quickly, so the team just keeps bulldozing that pile of crap along. By Version 3, the team is bigger and is still bulldozing that pile of crap but now the pile is much bigger and it’s spilling over the top of the cab and burying the team. Some teams never end up being able to ship Version 3 because the crap pile gets so big.
Apologies for the paleolithic references to versions “1, 2, 3” in our agile monthly release world. But significant new functionality takes time so call it “year 1, 2, 3” if that feels better.
Why does it seem that it is always the successful products that are such a pile of crap? Mostly it’s just selection bias. When a product is successful, the team has motivation to keep gunning the engine on that bulldozer, even if they’re getting buried in crap. For the failing products, the team just walks away and the code base dies out before it gets too big. Sure sounds like the Evernote team has been gunning the engine on that bulldozer for a while.
The second lens is the one I discussed in Complexity and Strategy. Basically, large products with lots of features are inherently complex. There are trade-offs and interactions and lots of different scenarios and features that need to be addressed. There is no magical refactoring that will make that complexity disappear. Ongoing development in such a code base is just harder than it is in the smaller, simpler code base of a smaller product. Applications that create sophisticated document artifacts are particularly complex and especially challenged by the need to remain compatible with all those valuable existing artifacts (and the user experiences and scenarios that have built up around them).
The proactive and non-fatalistic response is to recognize that if real complexity is inevitable, you need to invest significant effort in reducing the accidental complexity that builds up over time. Any application that has survived for almost two decades and had to move from desktop to span the rise of web, mobile, cross-platform and cloud will have a lot of accidental complexity.
This would provide a much friendlier perspective on Evernote’s efforts than applying the lens of Joel Spolsky’s classic “Things you should never do” essay on their project. In fact, the description of the Evernote project in the interview sounds much more like a cleanup than it does a grounds-up rebuild.
The counter-argument is that if you really aren’t doing a rebuild, the discipline of continuous stability and continuous delivery is way too valuable to give up. After leading multi-year projects for decades at Microsoft, I became a true believer in this more “agile” approach as I led Office from multi-year ship cycles to monthly ship cycles. The team delivered deep new functionality (e.g. real-time co-authoring) while maintaining a continuous stability and delivery discipline. Once you drink that Kool-Aid, you don’t want to stop. In this sense, it looks like Evernote conflated a resource prioritization problem (they were continually failing to allocate enough resources for ongoing architecture and “technical debt” work in the face of demands for new features) with an engineering strategy (forgoing shipping until major architectural work was complete).
When we made the transition in Office, many in Microsoft thought that what we were doing was “impossible” until we did it and then doing anything else seemed crazy.
