Dan Creswell wrote:
> Keith Harrison-Broninski wrote:
...
>>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.
The hardest problem is balancing the experiences and practices of the software
naive against the engineering drive of the software trained. But, in the end,
that's where software which interacts with users and solves people problems
needs to travel. Domain specific engineering is important and useability is a
very important domain these days.
> There's little in todays systems that's different from more than a
> decade ago - still multi-tier and more often than not still the 3-tier
> variety and we still seem to have all the same old problems of complex
> API's, messy deployment etc. How much progress have we really made?
> How much further progress will we make if we just accept what came before?
While I agree with this last line, I also have a fundamental issue with
continuing to change things when we see what you describe happening over the
past several decades.
Von Neuman computing and sequential programming flows drive us to solve
problems
in a particular way. Data Flow architectures are more along the lines of SOA
solutions today. Yet, we still don't have a predominate data flow based
language at the primary computing level. I did some work with dataflow
architectures and designed an interpreter for a dataflow language at
university.
It was truly a mind opening experience.
> No, good architects don't constantly re-evaluate the fundamentals of
> their profession but they have some pretty good, well proven, long term
> fundamentals (some of them borrowed from older disciplines such as
> physics) and arguably we don't.
What we have is too much to learn because more stuff keeps getting invented and
approved (by acclamation) for being "learn worthy". Artistians and creators
are
drawn to the software world. Alot of software people just keep on creating.
And, as in the art world, they develop followings that are based on comaradery
and good feelings more than sound, engineering based proof.
> So, sure we'll just use what came before and not question but then
> no-one can complain when it all turns out the same......
Since it has turned out the same so far, I keep complaining :-) I know a lot
of
people who would also complain, who just sit back and laugh. Good tools that
make significant difference in how software works need to include training and
examples as much as IDEs and app servers. For some, it's hard to imagine life
with a simple editor, the shell and 'make'. But, for years, we've had IDEs.
The level of integration was just different, and frankly, more configurable and
managable for the sake of decoupling build from development as well as the 10
second extensibility. Now days, extending an IDE with something new is a 10
minute job for some things, but more often than not that tool is not available
to others, and creates terrible dependencies between development and
build/deployment which will later be solve by a 10hour or 10day development
task.
Gregg Wonderly
> Thanks for the thought provoking post.
Indeed!
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/
