--- In [email protected], Keith
Harrison-Broninski <[EMAIL PROTECTED]> wrote:
>
> Apps, John wrote:
>
> > Great piece! The only comment I would add is that we need to
> > concentrate more on getting problems solved --solutions written--
that
> > we do on building and using wonderful IDEs, frameworks and so forth.
> > It is my opinion that we in IT still write way too much code, not
> > spending enough time solving the 'real world' problems, many of which
> > have already been solved using code up to 40 years old.
> > Regards, john
>
> > Andrew S. Townley wrote:
> >
> >> 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.
> >
> Thank you for these responses. I agree with both of you in terms of
the
> problems you identify. But I do not agree with either of your
> conclusions! Let me explain ...
>
> What is happening to IT, quite gradually until recently, is that it is
> changing from an amateur to a professional practice. Of course there
> have been professional IT staff since the 1960s, but until relatively
> recently most of them were not educated in IT - they came from all
sorts
> of disciplines, including the arts and humanities. And the approach
> most such people took to IT was extremely varied, and often governed by
> personal predilections as much as by breadth and depth of industry
> knowledge.
>
> Now, it's not a bad thing to have such people around. To the contrary,
> in areas such as user interaction design they are essential. And I
> myself had to choose at University which route to follow, so I know
from
> experience that there is no clear-cut division in mindset. However, in
> general, IT is becoming so complex these days that it's no longer
> acceptable to fudge together solutions - what we need are engineering
> practices, followed consistently.
>
> So, following this train of thought, how do engineers work? What they
> *don't* do, is re-evaluate the foundations of their profession every
> time they design a bridge. Except for the very few most brilliant
> leading lights in every generation, most engineers draw from a small
> number of tried-and-tested approaches to carry out their work, whatever
> the precise nature of each piece of work may be. And this is what I
> think needs to happen, and is happening, in IT.
>
> In other words, not only do we not have the time to understand the
basis
> of every framework, but such efforts are misguided. What we should be
> doing is going forwards by leveraging the advances of our predecessors,
> not continually deciding whether or not they got it right. To try and
> do so in fact combines several failures of duty - including in
> particular the arrogance to think your employer wishes you to spend
your
> time deciding whether you personally approve of how
> Eclipse/Spring/J2EE/etc were designed, rather than getting on and
> delivering the solution they asked you for.
>
> Now, I know I'm coming on strong here. But I really think it is beyond
> time for the IT industry to grow up. We call ourselves "architects".
> Well, let's start behaving like architects, then.
>
> --
>
> All the best
> Keith
>
> http://keith.harrison-broninski.info
>
I would just like to add the caveat that one is often given cause to
wonder how different buildings would be if architects were forced to
use and occupy them - but then would could often make the same
observation about car designers. Talking to some of the users of big
IT projects, similar issues often raise their ugly heads.
Gervas
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/
