Re: The MySQL/PHP pair

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:099jd.362414$MQ5.163359_at_attbi_s52...
>
> The very concept that I should have one person doing database management,
> another on networking, another on user interfaces, and still another
> defining business rules indicates a large cost structure. But that's just
> my perspective because I keep paying for all this.

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.

> Bill
>
>

Regards,

Dan Received on Mon Nov 08 2004 - 04:16:46 CET