After coming back from an expo, you're ecstatic. You saw a demonstration of a great new product; a Ruby on Rails podcasting system with a Section 508 compliant AJAX interface with built-in automatic transcription. Everyone else is doing it, it's got all the right buzzwords, and it's free! This will expand your organization's horizons and make you look like a technological genius. However, you need to take a moment to reflect on some key points before even thinking about installing your shiny new toy.
Justification
Why do you need it? Is this just to get in on what's hot, or does it serve a legitimate purpose and serve your client's best interests? Just because you can do something doesn't mean you should.
Is it really the best solution? Do some research on what other similar products are available; there may be better options that serve your needs.
Can everyone within your organization use it, or is your pet project? When you're part of a group, you need to consider the needs of others, not just yourself.
If others may be using it, how hard will it be to train them? You need to consider the lowest common denominator; it may be easy for you to use, but it may be much more difficult or impossible for others to use.
Do they even want to use it? There's nothing wrong with asking a few questions; you may find out that there's a better solution available that you hadn't considered or were even aware of. Change can be very scary and difficult for some individuals to handle; take that into account when proposing a new solution.
Maintenance and Support
How easily does it integrate with your existing system? Think of a square peg in a round hole. A hammer would get it in, but it would take a lot of work and would damage both the peg and the hole. While there may be no direct monetary cost for the software license, every minute you spend configuring, rewriting, tinkering, and fixing is a time cost.
Is it an officially released, mature product, or is it still in beta? If it's a mission critical application, then you don't want to use an incomplete or untested product.
How buggy is it? If the tool gets the job done, but only does it 3 times out of 10, then it's not not an effective tool.
Is the product the result of the work of a group, or an individual? This adds to the fragility of a product; if the sole developer is hit by a bus, then the project is also dead.
What kind of support is available? Sometimes, all you get is a 20 line text file in broken English. Other times, a complete Wiki and active forum or IRC communities can supplement the existing documentation.
Is the product still being actively developed? If there's a missing feature, who will add it? If you report a bug, who will fix it? It may have been great four years ago, but if nobody is working on it anymore, then you should seek other solutions.
Can anyone else in your organization maintain the new application, or are you the only one who knows how to keep it up to date? Once again, consider the hit-by-a-bus scenario. This isn't necessary a deal breaker if you keep good internal documentation.
Conclusion
Recently, I came back from a conference excited about Ruby on Rails, a free web application framework. I watched a manager (not a programmer!) create a feature complete forms-based front end to a database in about 20 minutes, and I was sold. I did the research, asked the questions, and it really does look like the best solution for some specific applications that we need to develop. Sometimes, the hot solution is popular for a reason. Just remember, while a great new product may excite you so much that you just about wet your knickers, take a deep breath, step back, and think it through.
Historical Note
In the 1978, approximately 913 followers of Jim Jones drank cyanide-laced grape Flavor Aid in a mass cult suicide.
No comments:
Post a Comment