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.
***************************************************************************************************
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
