On 2/10/2013 7:13 PM, Christopher Schultz wrote:
-----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
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
cents.
-Terence
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
