Hi Keith,
Must change my email settings as I'm only getting a fraction
of the
messages from yahoo, but I was just reading some of the
earlier
follow-ups from the web interface and wanted to address a couple
of
points you raised.
> However, the best chance of "quick delivery
[of] high-quality, robust,
> maintainable and operational software
intended to reduce the total
> cost of ownership over the entire
lifecycle" is to avoid re-inventing
> the wheel, isn't it.
Of
course it is. I wasn't suggesting you write every line of an
enterprise
application yourself (or any other kind, for that matter).
> As with
any framework, you have to invest time into Eclipse to learn
> it properly
- and this is always off-putting, which is perhaps the
> sub-text to some
of these responses - but you can get up to speed in a
> week, which is
fair enough for something that will save you many times
> that amount of
effort, as well as helping you write better code.
And I agree with you
here as well, but only the first part. Everything
has a learning curve.
Walking or riding a bicycle are "impossible"
until you've learned the motor
control and practiced it until these
things are automatic. Development
frameworks are no different. I
certainly wasn't suggesting a NIH (not
invented here) approach.
What the sub-text to my response really was is
this (and it relates to
one of the points that Patrick
mentioned):
What I have personally witnessed with my own eyes in dealing
with
software systems since I started using Turbo C++ back in 1990 and
has
become more and more easy to see each passing year is that
*because*
software systems have become so complex, it is virtually impossible
for
any one person to understand everything about them. However, the
real
danger here is that the fancier the UI and the "easier" it is to
use
components and APIs that you don't fully understand, the more prone
you
are to a) using the wrong tool to solve the problem and/or b)
including
features you don't need which increase the overall complexity of
the
resulting software and may introduce additional problems of their
own
due to accidental (in the Aristotle sense) interactions.
These
things don't happen on purpose. No one would willingly use things
they don't
need or purposefully use the wrong tool, but I very regularly
see the
software equivalent of shaving off the top of the door so it
will close vs.
moving/adjusting the hinges to solve the problem. From
the business
perspective, both of these solutions solve the business
objective of making
the door close, but it is not always a clear-cut
case which solution is
actually better in the long run. In this case
the real solution may be to
reinforce the foundation of the house and
save yourself further expense,
hassle and possible damage.
As the complexity of frameworks increases,
the likelihood of this misuse
happening must also increase, meaning that
either domain-specific
knowledge is required (e.g. the persistence layer is
written/maintained
by people who understand databases and
Java/C#/C++/Ruby or whatever, but
don't understand XML or services or
portals, etc.), or people must "do
their best" against often unrealistic
deadlines. I firmly believe that
the latter can directly increase the total
cost of ownership of the
delivered system over its entire operational
lifespan.
I'm not saying frameworks are bad--far from it. What I am
saying is
that there is a responsibility on the developers and
architects
employing those frameworks to truly understand what using them
means in
the context of a given solution. Context is key, which is why
"Best
Practices" should *always* be viewed with suspicion and also why
there
can *never* be "the one true way" of delivering systems.
I do
believe that frameworks can increase the productivity of
development teams,
and I do think that in some cases you can achieve
componentized software
within a set of constraints, but what I see
across nearly every vendor is how
pervasive the "pay no attention to the
man behind the curtain" attitude is
becoming. This really troubles me.
While we are lowing the barriers to
entry by making software development
more accessible with rich frameworks and
IDEs, I don't see a
corresponding growth in the knowledge and understanding
required to
apply them effectively. Just because the solution works, doesn't
mean
that it is effective. As an industry, I think we're focusing more
and
more on short-term thinking and speed of delivery than we are on
trying
to really teach people what they need to know to build better
software.
Sooner or later, I'm afraid that it'll turn around and bite us in
the
butt.
ast
***************************************************************************************************
The
information in this email is confidential and may be legally privileged Access
to this email by anyone other than the intended addressee is unauthorized. If
you are not the intended recipient of this message, any review, disclosure,
copying, distribution, retention, or any action taken or omitted to be taken in
reliance on it is prohibited and may be unlawful. If you are not the intended
recipient, please reply to or forward a copy of this message to the sender and
delete the message, any attachments, and any copies thereof from your
system.
***************************************************************************************************
