Setup is hard, and it wastes an extraordinary amount of developer time

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

I was just looking at this article, PHP with PHP-FPM, and it brought back memories of Timeout.com. All of the developers who worked at Timeout eventually had to set up the company CMS, and this was something of a hazing process, in that every developer later remembered the experience with dread. The CMS was a massive Symfony project — without question, the largest PHP code base I have encountered in 14 years of working with PHP. I’ll give you a sense of how massive it was: when I started working at the company, I was given a Mac with 4 gigabytes of RAM, and I tried and failed to get the CMS to work on this machine, and eventually one of the other devs told me “You can not get this thing to work on a machine with only 4 gigs of RAM. You need at least 16 gigs of RAM.” So then the IT staff upgraded my computer to 20 gigs of RAM, and I finally got the thing working. Even then, the pages took several seconds to render — and I was the only visitor to the site running locally on my machine!

Most developers wasted 2 or 3 weeks trying to get that CMS setup. It seems like a surprising cost for any company to bear, yet I hear similar stories from friends at many companies. I think setup should be one of those things that a smart company streamlines, mostly I think because bad setup is an anti-pattern that probably effects many parts of the company: the sysadmins, the hardware costs, the uptime, the long-term maintenance.

At Timeout, part of the problem was that there was no official way of setting up the site. Developers were invited to do whatever might work. The production machines used CentOS, but what do you do if you are running on MacOS? (The company was moving towards a standard VirtualMachine install for everyone.) There are a lot of ways to setup a PHP site, but if you try something and only get errors, you face the question: should you keep trying to get this to work, or should you try some completely different approach. Given enough time, a good developer will always get the site to run, but “enough time” might be a month — why would a company want to inflict that kind of cost on itself? Programmers are expensive.

The other big problem that comes up, when you allow all your developers to install things in their own way, is that suddenly the other developers are less able to help you when a problem comes up. Suppose you are working and you get an error that you’ve never seen before. You ask around and it turns out that no one else has ever seen this error. Some developer comes over to help you. They start making suggestions, but everything on your machine is configured differently than on their machine. They are using Apache, and you are using Nginx. They are using Ubuntu, and you are using MacOS. They install everything from a bleeding-edge custom repository (so they won’t even have the same config as another Ubuntu dev) while you installed everything with HomeBrew. All of the paths are different, most of the dependencies are different. Figuring out the problem is now a battle that all the devs must fight on their own, rather than as a team.

Post external references

  1. 1
    http://arstechnica.com/information-technology/2012/12/web-served-part-3-bolting-on-php-with-php-fpm/
Source