It took five CTOs to get rid of Drupal

It took five CTOs to get rid of Drupal

I joined FastCompany back in 2008. Not only was I suppose to make more money, but also it give me a chance to work with my favorite CMS at the time – Drupal! (yeah, I know…)

The interview experience was kind of intimidating, starting from the shiny new 7 World Trade Center building made of glass and steel. Later I learned that it was destroyed along with Twin Towers during the 9/11 terrorist attack and rebuilt from scratch.

Once I figured how to get to the 29 floor (elevators didn’t have any buttons) I was welcomed and stunned by the amazing view of the Hudson River. The lady upfront took me to another room in the corner. There I set for about 10 minutes looking at the rooftops of the lower Manhatten and Empire State Building spike on the horizon.

After hours of technical grilling by four future teammates, I was presented with the offer with I accepted right away.

Two weeks later I was sitting in the big spacious conference room with the giant desk and leather chairs on both sides, just like the one you see in the movies.

The room was full of people and at the head of the table sat my boss #1 Ed Sussman. He was full of energy, expressive and a bit funny. At the end of the meeting, I was given a chance to formally introduce myself and say hi to the tech folks. I think I mumbled something about my previous job and got a cheerful round of applause.

That’s the only recollection of Ed I have in my head because the next day I came to the office he was gone. Not exactly sure what happened, but something did. There were rumors that it was somehow connected to Drupal and millions of dollars.

It wasn’t long before we got the new CTO (and my boss #2). The position was taken by the young and charming Paul Maiorana. I liked him right away, mostly because he was a really nice guy. On top of that, he wasn’t very technical which created a very relaxed environment where we could focus on the projects of our own choice.

Noone really knew what we were doing and that was great! 🙂

Most of the people in the office used either Windows or Mac OS, but the computer that I inherited from the previous guy who left the same day I was hired had Ubuntu. There was also a sticker on top of one of the monitors that said: “Tungsten carbide star developer”.

According to other devs, the guy was a black-belt ninja programmer (the $300 Kinesis Advantage keyboard that he had sure did look very impressive), so I decided to keep the sticker and Ubuntu hoping that it would make me as smart one day, or at the very least force me to learn Linux.

Not going to lie, it was hard in the beginning, but it worked. Eventually, I became that weird guy who runs Ubuntu and uses Vim as the favorite editor.

The company’s main publishing platform was built on top of Drupal 6 and pretty soon we started feeling the limitations… There were so many customizations and core patches that it became hard to deliver new functionality without breaking something.

We spent more time trying to follow “the Drupal way” instead of simply adding what was needed. The whole UI was very coupled to the backend, there was no easy way to set up environments, run tests or db migrations. A lot of configuration was stored in db and some in files, which made it tricky to create multiple environments or roll out releases in a fully automated manner.

It was a mess.

When Drupal 7 came out we learned that there was no clear migration path. Not with our highly customized setup anyways.

The talks of complete rewrite became much more frequent, but we just couldn’t bring ourselves to actually doing it. Too much blood and sweat were wasted on creating what we had…

Then one day the big split happened. The tech department was separated into two, one for Inc and one for FastCompany. I ended up on the FastCompany side and Paul accepted a position at Automattic (the company behind WordPress).

After months of searching, we finally found the new CTO. Matt Mankins or my boss #3 was the MIT graduate, a true engineer and entrepreneur, extremely smart and technical.

The first thing that he did was to help us migrate our infrastructure to AWS, a move that was somewhat questionable and scary at the time, but it worked flawlessly (well, almost).

One day he invited me to his office and presented his new idea, a project codenamed Jetpack, which was supposed to help us get off Drupal once and for all. After years of working inside of the CMS paradigms, it felt like a breath of fresh air. A revolution! Nodejs, ZeroMQ, Handlebars, Resonators, smart API layer – everything was mapped out pretty nicely on the giant piece of paper.

Matt’s office walls were filled with diagrams and flow charts and his eyes were filled with wild enthusiasm!

He then asked if the whole Jetpack idea seemed like something I wanted to work on and I said “Hell yes!”.

Two years later we still had Drupal, but the front end part was handled by Jetpack. In order to do that we created a pretty complex publishing pipeline that would take Drupal posts, convert them into JSON then send them to Solr which was used as the main data source for the Jetpack APIs.

In the process of implementation, we discovered that Jetpack idea had quite a few limitations. Because of giant JSON context manipulation, it required very powerful machines. It always crashed, regardless of the infinite scaling potential that we designed for.

The whole thing was very custom, with big chunks written by Matt himself, which made it hard for new and old devs alike to understand how it was supposed to work and where to add new code… The AWS bills kept increasing and dev complexity increased even more as we now had to take care of two projects instead of one.

There were positive sides as well. We learned a lot of very valuable lessons and got out of the mental CMS trap.

At some point, Matt moved on to pursue one of his new startup ideas and his place was taken by CTO #4 Aaron Miller. Hired by Matt as front?-end developer, he coded quietly in the corner for a few months and then was promoted to CTO. Aaron continued to code heavily regardless of the new position and shortly after I was surprised to learn he was no longer with the company. Apparently, there was a revolt brewing amongst remaining devs that finally exploded on the day I was surfing waves at Long Beach (I meant to say working from home).

We continued to struggle with Drupal and Jetpack for three or four months before we were taken by the CTO #5. Tom Plunkett had the most experience compared to my previous bosses and was in charge of Gawker Media web properties before the company got sued by Hulk Hogan.

There were few things that stood out to me during our first conversation/interview in the same corner office with amazing views of lower Manhatten. First was his overall calmness. It seemed like he was interviewing us and not the other way around. The second was his answer to the “which language do you prefer to code in” question. He simply stated that even though he had a strong Java background, he would prefer to stay “completely hands off”.

Whaat? None of our CTOs were hands off, except for Paul, but he wasn’t technical to start with.

We bumped our heads more than a few times, but he somehow made shit happen. In a period of short few years we were able to get rid of both Drupal and Jetpack and migrated to vanilla WordPress (almost vanilla :)) for publishing and normal express/react app as the presentation layer.

What was his secret? He knew the process and the right people. To give you an example, he brought in Matt Hamer who almost single-handedly! migrated all of the data to the new platform. Without any prior Drupal experience, he worked meticulously until the project was successfully completed.

Takeaway: If you get stuck with some legacy project and no one on your team is willing to touch it with 10ft pole, it’s time bring on some high-quality fresh blood.

Yeah, it took us five CTOs and ~7 years to migrate off the legacy platform…

Think about it next time you are saying “let’s just add this CMS for now, we can always replace it with something better”. If you do it, then at least separate it into its own layer with solid API access. Trust me, short-term projects tend to magically transform into long-term ones. Spend some time and make it right, otherwise, you might be stuck with your “simple” choice for a long long time…

Unless you move to another company. Oh well…

Leave a Reply