12   Justify Technology Use

“You are starting a new project, with a laundry list of new technology and application frameworks in front of you. This is all great new stuff, and you really do need to use all of it. Think how great it will look on your résumé and how high-tech your new application will be with that great new framework.”

Once upon a time, co-worker Lisa explained her proposed application to Venkat: she was planning on using Enterprise Java Beans (EJB). Venkat expressed some concern as to how EJB would be applicable to that particular project, and Lisa replied, “We’ve convinced our manager that this is the right way to go, so don’t throw a wrench into it now.” This is a prime example of “Résumé Driven Design,” where technology is chosen because it will be nice to use and may improve the programmer’s skill set. But blindly picking a framework for your project is like having kids to save on taxes. It just doesn’t work.

Before even thinking about a new technology or framework, identify what problem you are trying to solve. How you even form the sentence makes a difference; if you say, “We need technology xyzzy because…,” then the battle for common sense is already lost. You need to start off by saying, “It’s too hard to…” or “It takes too long too…” or something similar. Now that you’ve identified a genuine problem that needs solving, consider the following:

Does it really solve the problem?

OK, this may sound blindingly obvious, but does the technology actually solve the particular problem you’re facing? Or, more pointedly, are you relying on marketing claims or secondhand advice to assess its capabilities? Make sure it does what you want without any deleterious side effects; write a small prototype if needed.

Will you be tied to this technology?

Some technologies (particularly frameworks) are a one-way trip. Once you’re committed to them, there’s no turning back. That lack of reversibility (see The Pragmatic Programmer: From Journeyman to Master [HT00]) can be fatal later on a project, when conditions have changed. Consider just how open or proprietary the technology is.

What about maintenance costs?

Will it end up being more expensive to maintain this technology over time? After all, the solution shouldn’t be more expensive than the problem, or you’ve made a bad investment. One project we know of spends $50,000 a year on a support contract for a rules engine—but the database has only thirty rules. That’s pretty expensive overkill.

When you look at a potential framework (or any technology, really), you may be drawn to the various features it has to offer. Then you might find yourself justifying the use of the framework based on these additional features you found. But are those additional features really needed? It may be that you’re finding problems to fit the solution you have discovered, much like an impulsive buyer at the checkout counter (which is exactly why they put that stuff there).

Not long ago Venkat came across a project where Brad, a consultant, had sold management on the use of a proprietary framework. Venkat saw that, while the framework was certainly interesting, it really couldn’t be justified on the project.

However, management was convinced they wanted to move forward with it. Ever polite, Venkat backed out, not wanting to be a stumbling block to their progress. A year later, the project was nowhere near completion—they had spent months writing code to maintain the framework and modifying their code to fit within it.

Andy had a similar experience where his client wanted to take advantage of open source—all of it, apparently; they had a “new-technology stew” so thick that they never actually got all the pieces to even work together.

If you find yourself building something fancy (and in the process developing your own framework from scratch), then wake up and smell the smoke. The less code you write, the less you have to maintain.

For instance, if you have a hankering to develop your own persistence layer, remember Ted Neward’s remark that “object-relational mapping is the Vietnam of computer science.” You can spend more time and effort building only what you need to build for your application—the domain or application-specific stuff.

Choose technology based on need. Determine your needs first, and then evaluate the use of technologies for those specific problems. Ask critical questions about the use of any technology, and answer them genuinely.

What It Feels Like

A new technology should feel like a new tool that does a better job; it shouldn’t become your job.

Keeping Your Balance

• Maybe it’s too early in the project to really evaluate your technical requirements. That’s fine. Perhaps a simple hashtable can stand in for a database while you’re prototyping and demoing with users. Don’t rush to decide on a technology if you don’t have enough experience to make the decision yet.

• Every technology has advantages and drawbacks. Whether it’s open source or a commercial product, a framework, a tool, or a language, be aware of the trade-offs that come with it.

• Don’t build what you can readily download. Building everything you need from the ground up may be necessary, but it is the most expensive and risky option.