epesh
I'm Joseph Ottinger, editor of TheServerSide.com.

Calendar

««Nov 2009»»
SMTWTFS
1234567
891011121314
15161718192021
22232425262728
2930

My Bookmarks

My Top Tags

                                       

Mailing List

My RSS Feeds








Search Box

 

There is no magic bullet.

posted Tuesday, 6 April 2004
There is no magic bullet. Managers and developers alike have a tendency to look for a simple, one-shot solution to address a series of complicated issues, even while we all acknowledge that there is no philosopher's stone. That fails to stop us, though - the search continues for some mythical fountain of ability (located in Florida or India, surely) against all applications of reason and sanity. Unfortunately, there's no replacement for actually rolling up your sleeves as appropriate for your current project.

In the end, every magic solution fails under the stress of reality: no project manages to fit itself into a given solution. It's the solution's responsibility to be flexible enough to compensate for the problem space.

Personal bias is inevitable, unfortunately. It's unrealistic to remove the developer from the solution, and just as unrealistic to pretend that the biases don't affect what the developer creates. Someone who's successfully used Hibernate for persistence tends to always think Hibernate's appropriate until shown otherwise, often through drastic failure. Likewise, someone who's had a failure with EJB tends to feel that EJB is inappropriate, even after being assigned to a project for which EJB is a good match. Few developers are able to correctly anticipate when conditions have changed in such a way as to controvert their own experiences.

Just as solutions aren't able to magically fit themselves into a problem, developers aren't able to do so either. Very rarely is a given hire - whether it's of a single developer or a group of developers - going to correct a project's problems, or yield a solution that involves no commitment. Even more rarely is a purchase going to make that kind of difference.

In my opinion, the best the industry has in terms of great solutions are tools like IDEA, Ant, Optimizeit, and a few others. The hallmark of all of these is that they are not solutions themselves. All are related to the creation of tuned solutions. Even more, none fit into the "popular product" mindset occupied by APIs and products like Hibernate or EJB, AspectJ or XDoclet, Struts or WebWork. All are one layer removed from those products, which workナbut fail in the "magic bullet" category.

Solutions tend to be general in nature, such as "manage a bank account" or "process a new policy." These are amorphous concepts, things with potentially very complex use cases (especially for general use, as you have to anticipate how all users will vary processes). As a result, it's horrifically difficult to get all of the nuances right, and I think even casual users can detect the assumptions made by developers and analysts.

The products I like are luckier; they're much simpler. Note that I didn't include products I use all the time in varying capacities: Eclipse isn't there because it's trying to be a platform and not just an IDE, and it shows - jack-of-all-trades, master of none. Same for NetBeans, with more emphasis on the platform side of things. JBuilder is an excellent development environmentナbut it, too, suffers from Borland's mindset, although parts of the suite - such as Optimizeit - are excellent and highly recommended.

The final result is that no one is going to able to solve everything without putting in time and effort. No product will suddenly solve your problems, no matter what the advertising (or resume!) says; prior experience simply isn't valid as an indicator for current issues. What you should look for is a person - not a tool - who understands that every solution is unique and is good at creating solutions, as opposed to someone who spends his or her time flaying the same historical data over and over again. There is no magic bullet - but there are people who are good shots.

Originally published in JDJ, under the title of "Looking for Instant Solutions?", April 2004.