Working with bad software

Movable Type is a blogging engine made by a husband and wife. It promises to take the hurdle of managing content of your website with a single solution. I've seen people who swear by it and I don't blame them. Every software sucks but if you spend enough time and effort you can make it suck a little less everyday. Movable Type is a solution for a multitude of problems and it does a good job solving them. But sometimes, it is also an awful choice.

I worked on a very popular website that used its own custom framework built in house. The article section of the website was handled by Movable Type. Because it was a big company, they used the enterprise version to handle multiple websites at the same time. This was a good solution as long as we didn't change any code on our end.

A Responsive Web was the new trend and every company jumped on the band wagon, including ours. We used the opportunity to upgrade from HTML 4 to HTML 5. We ditched the old designed for a cool flat design.

Other than the constant changes from management, the majority of the website was quickly upgraded. But working on the Movable Type section was a nightmare.

Side Note: This is not a bashing of Movable Type.

Movable Type was installed in the staging environment. You couldn't have a full copy of the website on your local machine. This is common for large applications. The problem however, was logging in from the web interface and saving your work via the web text editor.

When you make changes it saves it in a queue. There is a publishing CRON that checks the queue every 5 minutes and generate the necessary XML files with the update. When the files are created, they are saved in a network drive, which takes at least 5 minutes to sync due to the network settings.

When all your changes finally appear, you have a 15 minutes window, which started counting God knows when, to check the website to see if your work is correct. When the time expires, a CRON runs svn revert, which takes 5 minutes to update due to the network drive. If you wanted your changes to stay you had to commit your code first, but why would you do that before you have even tested it?

It was painful to work on this section of the website. What I did, was work on HTML copies of the website entirely on my local machine, then copy and paste it on the web editor and hope for minimum frustration. When I was absolutely sure, I'd commit the code and permanently see the changes on staging.

This was my first strategy. The other, was to log in the staging machine, and directly modify the xml files. The worst that could happen was that my changes were reverted in 15 minutes, and my work would appear after the 5 minutes delay. (sometimes less).

Every developer had his own strategy. Some swore that if you pressed CTRL+F5 at the same time you save a file, your changes would appear immediately. It never worked for me.

We all agreed that this section of the website made our lives a living hell.

The alternative.

WordPress. WordPress has its own quirks but all the developers in my team where very familiar with it. It would have been the perfect solution.

We were going to redesign the website anyway, so this was a good opportunity to make the switch. We could build a new theme matching the rest of the design and a simple script could convert all the Movable Type content to a WordPress database.

But, there was one problem. Movable Type is not free, we pay for it. There are more then a dozen sites that runs on it and all the new content editors are trained to use it. It is part of the system, thus was justified with a budget somewhere.

Making the switch meant changing the training process. And that was out of the question. In reality, editors don't even write the content on those engines. They write it in Microsoft word then copy and paste the result. (I know, I see these Áћñ all the time)

When the idea of making the switch is presented in a meeting, this is what people see:

Keeping Movable Type	Moving to WordPress
Make a few HTML changes	Rewriting everything from scratch
We already have a training process	Creating a new training process for old and new editors
Tested solution	This is a huge gamble, what if it fails?

We ended up not making the switch. It was a long and painful process to complete the responsive redesign.

---

WordPress could have had many advantages, at least in the development process. Every developer could have a copy of WordPress on their machine, and connect it directly to the staging database. Making changes is as simple as editing a php file. And WordPress is a heavily tested solution, all its quirks are heavily documented.

Training the editors might have seemed like a difficult task, but seriously, how hard is it to use WordPress interface?

The same goes to switching from any software. There were some websites that ran on Coldfusion and there were no developers that actively used it. Every time someone had to work on it, they would have to copy stuff from Stackoverflow to monkey patch the broken pieces, and it was always a different developer. Coldfusion itself is not a bad thing, but it was too expensive for the company to upgrade it.

As the person using the software, an upgrade always seem like a good solution. But it also means convincing a management that won't see head to head with you. Change is not welcome, even when it is for a good cause. If we could upgrade without affecting the training process, no one would complain. But that would mean creating a hack to convert Movable Type content to WordPress on the fly, which in itself could be problematic (think updates).

This is not Movable Type default behavior. Over the years, it was hacked together to create this very complicated process to work with the content team. It didn't make the work easier, it just justified some spending in a budget somewhere. We ended up with bad software we pay for that we cannot change.

That's the definition of bad software. A terrible process you cannot change.

---