Here's a nice explication of 'choose the right tool for the job,' by a pundit. The entire J2EE stack is often overkill, and I've seen shops that would have been much better served by a series of PHP applications, perhaps with java on the backend for heavier duty processing and legacy code reuse.
My only quarrel with his analysis is that he assumes we know how long an application is going to live. How many applications that started as prototypes get rolled to production and are the cause of endless headaches five years down the road?
As in any complex situation, when designing an application, and choosing how complicated to make its architecture, you need to balance between two principles:
1. It's easier to do things right the first time. You're in the code, you have an understanding of the requirements, there's a green field, you have a budget--therefore making sure the application works is easier when you're first writing it.
2. You aren't gonna need it. This slogan, from the Agile folks, says that you have no way of knowing what you're going to need five years in the future, so why try to design for that?
Taken too far, each principle is disastrous. If you follow principle number one fully, you'll end up in analysis paralysis. If you take point two to heart, you'll miss out on big chunks of functionality that have to be retro-fitted on later, to the detriment of a schedule and possibly the design.
That's why they (architects, not pundits) get paid the big bucks.
Posted by moore at October 6, 2004 09:03 AM | TrackBack