Coffee: IT contractors can't be expected to fight for client acceptance of unknown tools.Proponents of the exceptionally fine
Clarion development language and RAD tool were
arguing the other day about the importance of enterprise-oriented marketing for development tools and technologies. Some of Clarions independent-developer users, frustrated by what they saw as inadequate promotion, asserted that this was the biggest barrier to those whod like to make their living using the product.
Id have to agree thats probably the case, even if things should not necessarily work that way.
It would be a fine thing if custom application developers, or internal development managers, were free to shop for development tools and languages based on what delivers the best possible result. The problem is that intelligent people can reasonably disagree about what is the "result" of a development effort: Its easy to argue by what seems a compelling analogy, but completely miss that point.
I could argue, for example, that I dont know--or have any need to know--whether my plumbers wrench is a Craftsman or a Snap-On. This is the argument of the developer who says, "As long as I deliver a working application on time, why should I have to ask the client for permission to use the tool that makes me productive? Why should the development language be part of the specification? And why should I care if the tool vendor builds market acceptance for that product? Ill compete on my own performance."
For that matter, a development group might even consider it part of their edge that they use a tool unknown to most of their competitors. Ive often wondered, for example, if Ada gets so little attention because people who use it know that it works and have no interest in letting their competitors in on the secret. But I digress.
The crucial point is that I could also use the plumbers wrench analogy to make the opposite case. I could argue that I certainly would care if a worker uses a proper wrench that leaves nuts in good condition for future disassembly, instead of using a pair of pliers that gets the nut tight the first time--but leaves the corners of the nut so mangled that its almost impossible to take the fixture apart when it next needs repair.
I would likewise care if a plumbing assembly is performed with metric- or English-sized fasteners--at least, I would care if I considered that I were buying a Release 1.0 product, so to speak, and if it were my expectation that I would either maintain it myself or want to shop around for the talent to maintain or enhance that system in the future. There are comparable differences in ease of maintenance for software developed with various tool sets, programming languages, or programming frameworks or practices; there are certainly differences in my ability to find experienced personnel, to find training services and resources, and to shop for third-party code libraries and other infrastructure.
As to Clarions under-the-radar position in the development marketplace, I was one of two reviewers mentioned in that newsgroup thread as having said nice things about Clarion in the past; a forum participant wondered if the company had spent the price of a 37-cent stamp to stay in touch with a press release in the several years since I reviewed Version 5 in May of 1999. (That review is still online, but only--so far as I can determine--in Russian. And the AltaVista BabelFish translation makes me wonder if Im that hard to understand in English, too.)
But even a 37-cent stamp is more than a company needs to stay in touch: E-mail is free. And I have bad news for the current owner of the Clarion product, which acquired it almost three years ago: Unless Ive forgotten a communication from them during that time, this is the first Id heard of that change. Im pleased to learn that Version 6 is on the way, though, and I hope Ill have a chance to review it soon.
Meanwhile, my question to buyers of development services (either from in-house staff or from independent contractors) is this: Where do you strike the balance between getting the benefit of a developers judgment in choosing the best tool for the job, versus preserving your own future options by specifying the use of tools that are widely known? Are your costs dominated by the difficulty of writing specifications, so that productivity differences between one tool and another are insignificant? Or would the use of more productive tools give your people more time and inclination to be good designers?
And to vendors of development tools and technologies, my question is this: Who is your customer? Is it the person who buys your product, or is it the person whos ultimately going to pay for the work that gets done? When the question is put in those terms, the answer seems pretty obvious--and so is the need for development toolmakers to promote their return-on-investment proposition to all of the people whose investments are at stake.
Tell me if you prefer to have a secret weapon.
Most Recent Stories by Peter Coffee:
Application Development 
