|
|
All good developers are excited not only about the technologies they work with, but also about other elegant technologies. Outstanding developers can control this excitement when it's likely to cost their employers money. Developers have a natural conflict of interest with respect to the use of new and interesting technologies. First, there is the intellectual challenge. Then there is the resume imperative. Since agencies and employers usually begin by scanning a candidate's resume for buzzwords, acquiring new buzzwords (rather than deep new skills) is a priority. Think hard about the introduction of any new technology, especially if planning to introduce it to solve a single problem. A new technology once introduced may need to be maintained for years, complicating the organization's technology mix. What will be its implications for support? Will it require development skills used nowhere else in the system? Will it have special firewall or other requirements?
| Important |
Avoid using technologies for their own sake. Every new technology added to a project makes it harder to maintain, unless alternative approaches are clearly inadequate. Adding new technologies is a strategic decision, and shouldn't be taken lightly, to solve a particular problem. |
A real case in point: a large dotcom used an EJB server for business logic, with a presentation tier using servlets and JSP. A developer we'll call Joe was asked to develop an in-house administration tool to perform ongoing data migration. Joe's manager was trekking in the Himalayas, and all the senior technical staff was snowed under with a major release, so this was Joe's big opportunity to design and implement a solution. Joe spent a few minutes thinking about the problem and concluded that EJB wouldn't meet his needs and that a web interface couldn't deliver the functionality (both these assumptions later proved to be wrong). His solution - weeks late - involved RMI, with the interface a hefty Swing applet. Neither RMI nor Swing was used elsewhere in the system, except for the use of RMI under the hood by the J2EE server. The interface looked beautiful on Joe's machine, but the administration tool was abandoned within three months for the following reasons:
The use of RMI meant that an RMI server needed to be kept running. This was an additional unwelcome job for site management. The use of RMI also required additional firewall rules.
At least in this case, a Swing/RMI solution could have been made to work: although misapplied in this case, these technologies are proven. However, "neat technologies" are also often at the bleeding edge, making them inherently risky propositions.
|
|