Re: We're doomed
Date: Sat, 28 Feb 2009 16:06:32 GMT
"Roy Hann" <specially_at_processed.almost.meat> wrote in message news:87OdnWJw_qy7sTTUnZ2dnUVZ8gSWnZ2d_at_pipex.net...
> A colleague pointed something out to me a few years ago which I have
> found very useful ever since. In colloquial usage (i.e. anywhere but
> here), the terms "application" and "database" are completely
> interchangeable. Our customers and clients simply draw no distinction.
> The concept of an "information nexus" would be wholly novel to them.
I think that observation is very useful indeed. It certainly applies, in my epxerience, to non programmer users of almost any system. They view "the database" as the stuff that appears on the screen when they click certain buttons, and/or enter certain keys. In a way, I can empathize with that point of view a great deal. Why should they be concerned about layers that are invisible to them? They only know of these layers by hearsay.
However, with regard to programmers, the distinction between "the application" and "the database" is very important indeed. Some twenty years ago, I used to teach database programming to programmers whose prior experience included only files. Their languages included COBOL, BASIC, FORTRAN, C and a smattering of other languages. A very large percentage of them viewed interacting with database data as harder and less productive than using files for the same purpose, to very little benefit. Some of them were only learning database programming because management told them to.
I think a large percentage of programmers never get beyond this stage. One reason is that they never get the experience of dealing with a database whose design is well suited for its mission, whose update processes are well programmed, whose data is clean, and whose administration is competent. Until you've had this experience, it's difficult to grasp the "bang for the buck" that database enthusiasts like myself claim for databases.
Anyway, that's the way things were twenty to twenty five years ago. How have things changed in the interim? See below.
> Consider also that IT is still a very immature field and that most of
> its most senior and influential practitioners are the ones who drifted
> into it having first been clients.
IT remains immature much longer than many similar fields of endeavor have. Consider flight. From 1903 to 1953, manned flight progressed from box kites with moters strapped to them, and one pilot riding on the wing, to the B-52 and the DC-6 passenger liner. The engineering of new aircraft progressed from complete innovation to a well understood discipline, with design patterns that were well understood. Innovation built on what had already been learned, instead of junking all past knowledge.
By contrast, consider the field of programming from 1951 to 2001. 1951 was the year the first commercial computer was sold. In 2001, programming was still being viewed as a special "knack" that can't be taught and learned in a formal setting. Systems engineering, DBA work, and what have you was all being seen as being in such a state of flux that any knowledge that's more than 18 months old is seen as suspect.
There are serveral reasons things got to be that way. One of them is that mature workers in the field get fired so young, and can't find new work. The culture surrounding IT values youth even more than I do. I hasten to add that I don't think the field should stagnate, and that overemphasis on the mature worker could cause that result. But the field is tilted too far in the other direction.
There are other reasons, but I'll stop for now. Received on Sat Feb 28 2009 - 17:06:32 CET