Comments on: Too Many Choices? http://www.breddy.net/2006/08/08/too-many-choices/ Personal and professional weblog of Chris Bredesen Sun, 06 Jun 2010 06:09:44 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: JoshDM http://www.breddy.net/2006/08/08/too-many-choices/comment-page-1/#comment-81 JoshDM Fri, 18 Aug 2006 16:46:54 +0000 http://www.breddy.net/2006/08/08/too-many-choices/#comment-81 I come from a "re-invent the wheel" sentimentality. But fortunately, I've seen the error of my ways. There are too many wheels out there, each with their own iteration on the spinning hubcap. Which wheel the best for you? The one that requires the least amount of tire protectant application, or allows the easiest maintenance and customizability. And therein lies the ultimate dilemma. By the way, Appfuse. I come from a “re-invent the wheel” sentimentality. But fortunately, I’ve seen the error of my ways. There are too many wheels out there, each with their own iteration on the spinning hubcap.

Which wheel the best for you?

The one that requires the least amount of tire protectant application, or allows the easiest maintenance and customizability.

And therein lies the ultimate dilemma.

By the way, Appfuse.

]]> By: Rob http://www.breddy.net/2006/08/08/too-many-choices/comment-page-1/#comment-77 Rob Wed, 16 Aug 2006 13:12:52 +0000 http://www.breddy.net/2006/08/08/too-many-choices/#comment-77 And with new versions always on the horizon, not only do you have to contend with which technology, but which version! Struts 2.0 vs. Struts 1.9. Spring 2.0? And with new versions always on the horizon, not only do you have to contend with which technology, but which version!

Struts 2.0 vs. Struts 1.9.

Spring 2.0?

]]> By: Kris http://www.breddy.net/2006/08/08/too-many-choices/comment-page-1/#comment-65 Kris Wed, 09 Aug 2006 12:02:36 +0000 http://www.breddy.net/2006/08/08/too-many-choices/#comment-65 Making decisions about what api/framework/server/jdk is something that a lot of people get wrong time and time again. There are so many factors, such as, support, documentation, maturity, user/developer ability, scalability/performance, etc and inevitably one of these gets overlooked or made out to be more important than it really is. So, I tend to stick to a core stack of the things that do a good job of covering all of the above most of the time which make the simply things quick, but has the power/functionality to scale up to deal with Enterprise level applications. Spring is a great example of this IMO. Once you've got your basic stack covered, e.g. (Spring/Hibernate/Tomcat/JDK 1.5) which you/your team/company are familar with and which you know does the job well most of the time, you can then free up time to consider the specifics of project that might really benefit from the adoption of something new/different. And I think it's important not change everything project to project, just because it's the latest and greatest. If your previous stack was jsp/struts/ejb/websphere and you decide the next project your team is going to do will be velocity/spring/hibernate/tomcat then any productivity gains are probably going to be eaten up by the ramp up time and naive usage first time out. I've seen this time and again, where good, experienced developers cut themselves on the bleeding edge in this way trying to take on too much in one project, myself included. Making decisions about what api/framework/server/jdk is something that a lot of people get wrong time and time again. There are so many factors, such as, support, documentation, maturity, user/developer ability, scalability/performance, etc and inevitably one of these gets overlooked or made out to be more important than it really is.

So, I tend to stick to a core stack of the things that do a good job of covering all of the above most of the time which make the simply things quick, but has the power/functionality to scale up to deal with Enterprise level applications. Spring is a great example of this IMO. Once you’ve got your basic stack covered, e.g. (Spring/Hibernate/Tomcat/JDK 1.5) which you/your team/company are familar with and which you know does the job well most of the time, you can then free up time to consider the specifics of project that might really benefit from the adoption of something new/different.

And I think it’s important not change everything project to project, just because it’s the latest and greatest.

If your previous stack was jsp/struts/ejb/websphere and you decide the next project your team is going to do will be velocity/spring/hibernate/tomcat then any productivity gains are probably going to be eaten up by the ramp up time and naive usage first time out. I’ve seen this time and again, where good, experienced developers cut themselves on the bleeding edge in this way trying to take on too much in one project, myself included.

]]>