-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Terrence,
On 2/9/13 8:01 PM, Terence M. Bandoian wrote: > On 2/6/2013 9:26 AM, Jeffrey Janner wrote: >>> IMO, developer performance trumps runtime performance most of >>> the time. >>>> So, if you can create a more maintainable system in less time >>>> by using EJB (or whatever), then you go ahead and do it: >>>> servers are cheap, while developer time is expensive. >>>> >>>> - -chris >> Chris, I'd like to differ with you on this last point. As someone >> who's been a developer, support person, and admin, I've got a >> pretty good perspective on this subject. While servers may be >> cheap, they will never be cheap enough to overcome poor >> programming practices. I've worked with systems so poorly >> designed that we couldn't purchase a system big enough to run the >> software adequately, once you got above a handful of users. Yes, >> it's gotten to the point where systems are much cheaper than they >> used to be, while developer salaries are only increasing >> (supposedly), so wasting time on some minor performance >> improvement may not be cost-effective. However, when you >> aggregate the time that hundreds of users spend waiting on a >> response from a poorly designed, unresponsive system, I think >> you'll find that it trumps the cost of having the developer >> spending a few extra minutes to "get it right the first time". > > Generalized solutions, I think, include a substantial amount of > code that isn't required for a given application. The additional > code affects performance but with the speed, availability and low > cost of hardware, people seem to be opting for packaged solutions > that don't require their programmers to understand the details of > the implementation. That seems short-sighted to me. > > As an aside, I wonder if, at some point, the energy costs of > inefficient code will come into play. Don't wasted CPU cycles == > wasted energy? There is always a balance between a number of criteria: 1. Cost to run (CPU time) 2. Cost to build (programmer time) 3. Performance 4. Maintainability IMO, issues #2-#4 trump #1 every time: maintainability is the most important aspect of software design. If using JPA means that you can maintain your software more effectively, then it is totally worth the extra cost of CPU time. Anyone who has ever worked at an outfit where there is some legacy code that you can't touch because nobody understands how it works knows that this is the truth: there is unmaintainable code that someone wrote in the past and then left/got fired/died/etc. and not the only options are a) leave the code alone forever in fear that it will break if you touch it or b) completely re-write the code. If you have some cowboy who writes thousands of lines of impenetrable JDBC code, you have a recipe for code rot. Use of Hibernate, JPA, etc. can significantly alleviate that because - at least for non-abandoned projects - there are many people always looking at the code, and they are experts in that code. The 3000€ per annum is nothing compared to the cost of re-writing all that legacy code, even if you switch from (e.g.) straight JDBC to (e.g.) Hibernate or JPA. If you have to pay a consultant to do that, it's going to cost you an order or two of magnitude more than the cost of hardware: you can run more hardware for the lifetime of the software rather than make a big change like that across all your code. That said, when (or if) you run into performance problems, then you have to decide whether you need to ditch the framework (perhaps just for a portion of your code). We ditched O-R mappers for different core reasons, but maintainability was the primary one: they all required too many hacks at the time to make it worth it. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEYRcYACgkQ9CaO5/Lv0PBpVgCghvN48DZnEs8OUgl1aZJPWaJA Jq4AniQEI++Gez6es5U+gxCAry+LaflY =+UJg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
