On 2/12/2013 9:36 AM, Christopher Schultz wrote:
On 2/11/13 4:30 PM, Terence M. Bandoian wrote:
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.
Are you suggesting that people who program using Java are oblivious to
the innards of hardware architecture and are remain ignorant of these
important details? That's the logical conclusion to your argument.
I'm not saying you're wrong, but you have to admit that a Java
programmer (of which I'm one) saying that using a generalized solution
makes you ignorant is a bit like the pot calling the kettle black.
Not at all. I probably should have said there is a "potential for
lost knowledge". Here are a couple of anecdotal examples that I hope
will help illustrate what I mean.
- I was told recently by a person in a software architect position
that they use Hibernate because it prevents SQL injection. I'll give
them the benefit of the doubt and assume they have other motivations
but still, is escaping the input strings to a query really advanced
knowledge? Think about that from the perspective of a junior or
mid-level programmer who has only ever used an ORM. What happens when
something goes wrong or performance has to be optimized. For that
matter, what does happen? Now you have to know SQL, the DBMS, and HQL
and understand Hibernate behavior. Double the complexity?
Disclaimer: I don't have anything against Hibernate or JPA. I worked
with an early implementation of JDO for a short time and am beginning
some work with Hibernate.
- A JavaScript programmer told me not too long ago that you really
have to use a JavaScript library (e.g. jQuery) if you're going to use
AJAX in an interface because it's just too complicated. Is
instantiating and using an XMLHttpRequest object really that
difficult? What about those programmers who have only ever used a
JavaScript library? Another developer says he tells clients that they
shouldn't consider a feature if it isn't supported by jQuery. Still
another says that one of the reasons their organization uses a
full-blown framework is that their programmers can't develop
cross-browser compatible JavaScript.
Disclaimer: I think jQuery is a wonderful library and, if you plan to
make good use of the features available, it should definitely be
considered.
What I'm saying is there should be a good reason (really good) to add
significant complexity, performance overhead, memory requirements and
megabytes of code to an application.
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.
In my experience, by far the biggest time waster is trying to deal
with code that is (or has become) unmaintainable. Re-writing just
because a piece of code has become out-of-touch with current standards
or because nobody understands how it works is entirely wasted effort.
We have lots of places in our code where we have been spending -
literally - years recording from bad decisions in the past.
Granted. Reading other people's code is a learned skill and can be
problematic. Isn't that where design and code reviews and coding
standards come into play? Also, apples and oranges. Energy is
precious resource that deserves special consideration. I'm just
blue-skying here and don't have the answers but how much electricity
is wasted by inefficient programming? We may have to factor that in
some day.
-Terence
From Christopher Shultz 2/14/2013 (comments inline):
Terrence,
On 2/14/13 1:23 AM, Terence M. Bandoian wrote:
> I probably should have said there is a "potential for lost
> knowledge". Here are a couple of anecdotal examples that I hope
> will help illustrate what I mean.
>
> - I was told recently by a person in a software architect position
> that they use Hibernate because it prevents SQL injection.
:)
So, it doesn't support custom WHERE clauses? Sounds like a
deal-breaker for me. If it does support custom WHERE clauses, then
it's open to SQL Injection because programmers can still suck.
> - A JavaScript programmer told me not too long ago that you really
> have to use a JavaScript library (e.g. jQuery) if you're going to
> use AJAX in an interface because it's just too complicated. Is
> instantiating and using an XMLHttpRequest object really that
> difficult?
No, but if you've ever done your own AJAX work (and not just something
silly like sending a ping to the server or trading a 2-line XML
document), you'll know that using a support library makes your life
soooo much easier, especially when you have to support multiple
browsers/versions/etc.
Good news is that you can mix-and-match: if jQuery (et al) doesn't
support some feature, you can write it yourself and (probably) not
interfere.
> Still another says that one of the reasons their organization uses
> a full-blown framework is that their programmers can't develop
> cross-browser compatible JavaScript.
It *is* very difficult: when you can leverage the work others are
doing, I think everybody wins. Let the jQuery folks figure out how to
make XML parsing and call-backs work on both MSIE 6 and NCSA Mosaic:
NMFP. ;)
> What I'm saying is there should be a good reason (really good) to
> add significant complexity, performance overhead, memory
> requirements and megabytes of code to an application.
Leverage is a powerful thing.
>> In my experience, by far the biggest time waster is trying to
>> deal with code that is (or has become) unmaintainable. Re-writing
>> just because a piece of code has become out-of-touch with current
>> standards or because nobody understands how it works is entirely
>> wasted effort. We have lots of places in our code where we have
>> been spending - literally - years recording from bad decisions in
>> the past.
>
> Granted. Reading other people's code is a learned skill and can
> be problematic. Isn't that where design and code reviews and
> coding standards come into play? Also, apples and oranges. Energy
> is precious resource that deserves special consideration. I'm just
> blue-skying here and don't have the answers but how much
> electricity is wasted by inefficient programming? We may have to
> factor that in some day.
Future-proofing is not possible, but it is a reasonable goal. All
software rots, even if it's great software. Take Java code: anything
written before generics were introduced and uses a lot of collections,
etc. will now be a PITA to work with. I have code like this: we are
updating it as we have to edit it for other reasons (e.g. we aren't
going on a S&D mission for non-generic-y code just to "fix" it), but
it does represent some technical dept that does need to be paid at
some point. Maybe the existing code is so good that it never needs to
be edited, so it sits there and rots, and there are more things
"wrong" with the code but it works perfectly well. It becomes
something that irritates everyone but everyone tolerates because it's
"good" code.
------------------------------------------------------------------------------------------------
The generics problem doesn't seem like that big a deal. Add types to
your declarations and remove the casts. If the software already works
without generics, the hard part is done. Converting is purely
mechanical and the compiler will pinpoint the lines that should be
changed for you. Also, if you can make the changes in the course of
some other modification, they really don't represent a lot of
programming overhead (or technical debt as you call it). In some cases,
you might not even want to convert.
------------------------------------------------------------------------------------------------
If you can make some code someone else's problem, I think that's a
win. It's very cynical, but having grown-up in the Java world before
any "good" libraries were available (other than the standard Java API,
which is great by any standard IMO), I've been party to a lot of time
and energy spent just doing simple things like trashing some cowboy's
home-grown logging API, O-R mapper, and (yes, true story) XML
transformation engine.
"Not invented here" is a pesky disease and it's really okay to
leverage other people's code. There are always exceptions (I've
written my own rules engine from scratch when DROOLS, JESS, etc.
already existed) but you (not YOU) are a fool if you don't consider
using something off-the-shelf -- especially if that shelf contains
lots of great OSS and you can help support it.
------------------------------------------------------------------------------------------------
If you recall, I said there should be a really good reason to add
significant complexity, performance overhead, memory requirements and
megabytes of code to an application. I didn't say there weren't any.
And I never advocated eliminating "off-the-shelf" software as a
consideration.
-Terence
------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
