Technology is a moving target.
The target moves for a variety of reasons most of which are good: advancements, improvements, increased efficiency, and so on. While it is a challenge to keep up, adopting change that yields an increase in value is usually worth the pain to change.
VisualShare manages this change everyday. Staying up with things takes a lot of effort but usually pays off in customer satisfaction and helps create a technical moat around our products.
However, when the target moves for what seems to be no net increase in value, the outlook turns bleak very quickly.
I was reminded of such an occasion (moving target->chase->no net value) helping a scientific researcher colleague of ours install Movable Type a blogging package written in Perl (and some PHP). In fact, I am writing this blog using Movable Type.
Overall, Movable Type it is a great program and I have installed it twice before attempting to install it for this friend. The documentation is average, but the tools used are common on most *NIX systems (RedHat, FreeBSD, etc.) meaning that the install is usually straightforward and takes under an hour of time.
Here is the left hook:
He wanted it to run on MacOSX. Don't get me wrong, I love MacOSX (See prior post Windows != Easy). I love it as a desktop and their server environment is very easy to use until...you do something a bit more complicated.
Installing Movable Type is not hard per se. What is hard is that the MacOSX is a moving target when it comes to relying on a common OS setup for Apache (Web Server), Perl (Programming language), and MySQL (database storage).
At VisualShare we have bumped into this wall numerous times thinking that MacOSX Server would provide a very stable, easy to manage server environment. But, that server environment changes frequently so that a prior setup--Movable Type in this example--is broken by changes in how MacOSX updates the XAMP (OSX, Apache, MySQL, Perl | PHP | Python) environment.
When I set out to install Movable Type on MacOSX for my friend he had a nice tutorial written by someone and posted on the Web. Everything went smoothly until I went to install the Perl database interface for MySQL (DBD::MySQL).
The tutorial was written for version 3.0008. The newest version of DBD::MySQL was 4.something. The typical Perl module installer called CPAN uses the current version when running installations which is usually a good idea...unless there is a quirk in the environment.
And there was such a quirk.
In the end I had to hunt down a few other articles posted on the web that described successful DBD:MySQL 3.0008 installs and run an install manually of 3.0008 instead of 4.
While this does not sound like rocket science and it wasn't, the real problem is that I did not know exactly what problem I was solving as the target so to speak had moved.
This ever so slightly moving target caused my friend quite a few hours of frustration and me about 2 hours more than it should have. That is a lot of effort to something that would typically take under an hour.
The take home point is be careful about relying on changing environments and dependencies.
Message to Apple: You make great products. But, please do not move things around.
