Re: The MySQL/PHP pair

"Dan" <guntermann_at_verizon.com> wrote in message news:yyBjd.1495$SC5.1446_at_trnddc01...

> I actually think you have a valid point here. My software engineering
> classes (from way back when) actually focused on the software engineer
being
> more of a generalist to cover all aspects of the software development and
> system support life cycle, from requirements gathering, architecture,
> design, modeling, project management, configuration management, testing,
> implementation, and maintenance. The real objective wasn't to have one
> person do it all, but that any generalist could easily slip into any role
> and have a clear understanding of how his or her role supported other
roles
> and fit into a cohesive development/maintenance effort from a global
> perspective.
>
> Like everything else, I think there are trade-offs. We have seen
parallels
> in the businsess world as well. The pendulum swings back and forth
> depending on what the objective function is, or what it becomes. Usually
as
> one approach comes to an exterme, it swings in the other direction,
> eventually reaching a threshold to a point where the enterprise reacts. I
> can't remember exactly, but an IBM case study demonstrated the value of
> generalists from a business perspective.
>
> From one perspective, there are specialists each confined to their small
> area of focus. This type of approach seems to usually have the benefit of
a
> high degree of competence and service for areas of small scope, but has
the
> potential liability of high cost and a high risk of failure in terms of
> requiring overhead to manage and coordinate what eventually become
isolated
> islands to support a larger a cohesive larger objective. More often than
> not, inefficiencies seem to occur and the task of getting everyone to
seeing
> the forest for the trees becomes extremely tough. Finally, there is the
> danger of native knowledge and people protecting turf rather than working
> together.
>
> Sometimes this approach goes to lengths of absurdity. For example there
are
> cases where DBA's who can run a production database system as an
> administrator, but don't know the first thing about conceptual modeling,
> relational models, or the information their DBMSs hold; analysts who
gather
> requirements, but can't model the requirements in a way that is conducive
to
> being translated into an efficient implementation; siloed data stores
based
> on function; siloed and disparate data stores based on application,
> organizational, or administrative domains; programmers familiar with and
> very good with one type of coding, but can't formulate a design spec or
work
> across programming paradigms to save their life, and the list goes on.
>
> I've also seen extremes where the data management discipline itself is
> partitioned into specialists of extremely absurd levels of granularity:
> data quality specialist, data modeler, ETL specialist, database designer,
> database application coder, data analyst, data steward, information
> architect, etc. Often these people work independently of one another.
This
> seems rather silly because they are all interdependent.
>
> The generalist approach has its own set of problems, though it is more
> appealing to me. The first problem with having generalists that I see is
> that there are far too few competent ones that actually have dedicated
> themselves to mastering, or even becoming familiar, with the fundamentals
of
> information technology, software engineering, and information technology
in
> general; in addition to the broad array of technical and functional roles
> that support each other. These type of people have education tempered
with
> experience (for real and not just on a resume). The second detractor is
> that systems are too complex for a small set of individuals to do it all.
> I'm sure there are more, but I think these two are a good start.
>
> I imagine there is no perfect answer. I think both improving education,
> enhancing hiring standards, and finding the right balance is the key. I
> don't think a particular technology is the answer.

These are all good points. You may have brought this topic back from the brink.

I think that, in particular, database design was not taught very much at all in the 1985-1995 time frame. And even to this day I meet people who are otherwise well rounded IT professionals who have almost no clue about how to design a database (relational or otherwise), and in addition think it's something easy, dull, and tedious, like setting up a filing cabinet.

About DBA's even seen the gamut: people who do backups and authorize users all the way up to people who are the ONLY PEOPLE IN THE IT DEPARTMENT WHO KNOW HOW THE BUSINESS REALLY WORKS! (Sorry for shouting... I feel much better now.)

But I'd have to say that it's unusual to run into DBA's who don't know simple design.

Anyway, the thing that bothered me about Bill's response was the leap from "I had to give up my vacation because they spent money on an untested technology" to "Dawn gets it, the RDM has not lived up to its promise." That's an enormous leap, and it's completely unjustified.

And the idea of avoiding, "hey let's try this new technology" is precisely the reason why the history of the development of relational databases compares favorably with, say the history of the development of operating systems or compilers. There was a great deal of thought (theory, one might say) put into the probable consequences of building the system one way versus another. And I'd have to say that the RDM, even with the SQL tattoo on its arm (or wherever), is in better shape than most of the rest of IT. Received on Mon Nov 08 2004 - 04:52:38 CET