Goldberg Machine
Goldberg Machine
Michael Tucker
Wed, 08/15/2012 - 15:06
When I was a kid, we had a game called Mouse Trap that was based on the Rube Goldberg machine concept. The game pieces resembled common household items like a bathtub, shoe, plumbing pipes, a ladder, etc. You took turns building a trap, piece by haphazard piece. If you were successful, you’d have a complex but fragile working trap to capture the other players’ mouse. But while you built, the constant danger was that you might touch one piece or another and ruin the trap: game over.
An interactive agency with open source development expertise, Bluespark is often asked by prospects or clients to assume developmental control over an existing site. With increasingly alarming frequency, we often find that the site is poorly conceived and inexpertly built. Often what we find is the web equivalent of a Goldberg machine.
Here is a sad fact in this business: there are plenty of people, often quite professional in other fields — like designers or agencies — who learn a little bit about code, throw together a few experimental sites and then hang out a shingle as a 'web company'. Frankly (and this might sting a little) these people have no experience developing complex software, which is what a well-conceived Drupal site can be.
There are some telltale signs. If there’s no staging server, no code repository, and no launch procedure, we have proof enough that the previous team did not have a familiarity with professional code development standards. Of course, Bluespark has the expertise to set up an environment and sane code management procedures, and can begin hacking away at a site like this and eventually get everything untangled and/or rebuilt in a way that makes sense.
But there are huge risks.
Suppose you win a big client who needs a rescue. Congratulations. You're the web team now, and you're responsible for a Goldberg machine you did not create.
The previous guys somehow managed to get the site to a stable point - likely way over budget and way off schedule. They’re out. You’re in. You’re asked to improve the site. You can chase down the errors and fix them, but always at the risk of causing another problem somewhere else. Surprise! You've touched the wrong component, and the site has blown up. You bravely soldier on, trying to find a way to get it all back to stability. In the meantime, all eyes are on you because, "It was working until you touched it,” and “What are these delays?” and “This is costing us money!" You didn’t build it, but you’re catching the heat.
No one will remember who created this mess. Very quickly, the client’s perception of the "Web team" becomes synonymous with "web site" and inherits all of its problems. If the web site sucks, then the web team sucks.
That's the nature of the beast. Trust me, it is not good for an expert to be in this position.
A Goldberg system is only marginally operational at any point in time. So when everything works, it is only for a short period. The moment you start tinkering and improving you're instantly back to a zero sum game. You can't win because you can't predict what the overall effect of the tinkering will be.
With a site like this you are always going to be in a state of either flat-out emergency or semi-emergency, simply because you always want to improve it. The reality of working on a delicate system causes unpredictable issues, which become emergencies. The only way to stop the cycle is to get it to where it semi-works and *don't touch it* and then build a non-goldberg machine with the same functionality on another server.
But because the site mostly works, the temptation, particularly for your non-technical client, is to keep futzing with it and trying to improve it. But it never gets there. As a consequence, your client is in a constant state of panic and continuously throwing money down the drain.
Here’s the only solution. As soon as you identify your Goldberg, blow the whistle.
As a service provider, you might think you can just keep plugging away at it. You could, and eventually you might turn the site around. But often the best thing for you and for your client is to stop, recognize the situation, and rebuild. Even though the financial hit could be significant and immediate, ultimately the bottom line is that a stable, extensible, scalable site is cheaper to run over the long haul.
If you don’t, you perpetuate an untenable situation for you both. The longer you wait, the more it will feel to your client like you’re abandoning them and giving up.
So show your expertise, show your professionalism and if needed, be willing to walk away. Let someone else trap that mouse.
Filed Under
Drupal Planet
Drupal
Best Practices
Add new comment
Area
Resources
CTA