tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Mon, 11 Feb 2013 21:30:16 GMT
On 2/10/2013 7:13 PM, Christopher Schultz wrote:
> 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


I understand the considerations above and they are a part of the 
prevailing thinking. However, one underlying assumption of the 
supporting argument appears to be that today's programmers are not 
capable of developing maintainable code which I don't believe is true. 
As I understand it, programmer productivity is one of the most 
significant factors in the decision making process and it is a valid 
concern. IF (that's a big if) an application can be developed in half 
the time using a generalized solution, then that approach has to be 
considered along with a host of other concerns including the end product 
and the effect on the organization. I say reliance on generalized 
solutions is short-sighted because knowledge of the underlying 
technologies is lost, or never gained, along with the skills to work in 
those spheres.

Efficiency, flexibility, repairability, extensibility and reliability 
are all components of software quality and all are affected by 
complexity. Less complex systems are easier to maintain.

To continue the aside, wasted energy is wasted energy and it may become 
a factor in software development at some point. I think decision makers 
should be taught that there is more to the bottom line than dollars and 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message