When recommending a solution to a client, I’m easily tempted to go with what I know or like best — but of course I owe it to the customer to recommend what will work optimally for them long after I’ve moved on to other engagements. I’ve often found that what fits their need depends not so much on technology as it does on culture and prior investment.
Ruby (and Rails) makes development both easy and powerful, by trusting the developer with great freedom. You can do virtually anything you want, even modify the framework itself or all classes in general (sometimes with unintended consequences). So before you can recommend using Ruby for a project, you have to know that your client can trust their programmers to innovate. If they’re all enchanted with type safety and “best practices” and protecting the programmer from (him|her)self, then they’ll be much more comfortable with .NET. If their existing servers are all running IIS and their programmers already know VB or C#, that’ll seal the deal.
JSON may be cleaner than XML, and a RESTful API is simpler than a SOAPy one. But if your client needs to consume existing services made of envelopes and angle-brackets, it may be better for them to continue using the old bad standard than to build a translator to the new and improved one.
The ideal technical solution might best be written in Lisp, but it ain’t gonna fly unless the programmers can achieve parenthesized Zen whenever coding is required.
I’m sounding pretty fatalistic here. The consultant also has a duty to introduce clients to new technologies that can make their lives better. But most companies adopt such changes slowly and carefully. Beware of trying to import a revolution, unless that change has already been initiated from the inside.
