Re: [service-orientated-architecture] Re: Platforms for SOA

Sat, 05 Aug 2006 02:10:36 -0700

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
__._,_.___


SPONSORED LINKS
Computer software Computer security software Computer software program
Computer fax software Computer virus software

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to