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 cpnsequences). 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.
That's not to say that such organizations don't exist, of course. I know for a fact they do -- but I haven't had the dubious pleasure of needing to rein in a client on that side of the fence. From what I've seen, the companies that want to move too fast are usually consultancies and the like, not client organizations. I take great care to avoid falling into the trap of recommending too much advancement too quickly, not only because taking such advice to the logical extreme too quickly can lead to disaster, but also because doing so would be more likely to result in losing a client than in someone taking such poor advice too readily.
In principle, for instance, I will almost always tell you that an open source system is a better bet than a closed source, proprietary alternative (all else being equal) -- but in practice, such a migration first requires years of cultural preparation within an organization. One client that I ultimately moved to Linux servers (and essentially lost the client because I was no longer needed to provide the constant support for failing MS Windows systems -- but I was happy to lose a client to good work that way) took eighteen months to go from 100% MS Windows to a combination of MS Windows desktops and Linux servers. To give you an idea of the sort of glacial pace of such changes in business, it took that 18 months for an office of three people.
Too quickly? No, I've never dealt with a client that adopted too many new technologies "too quickly". Have you had such an experience?
9
No comments:
Post a Comment