Just Say No to Specialization

One of the topics of our standup meeting this morning was the communication problems with the database group. At the eleventh hour they wanted to change the names of tables, columns and constraints. While I suppose there's nothing too much wrong with caring about consistent naming conventions, I question a lot of the specialization that happens in larger IT shops nowadays.

I read this quote on Apple's Pro site:

Where these big shops have tiers and tiers of people focused on something specific and get bogged down by their infrastructures, we can win a huge campaign with just two artists and a Mac.

...and I can't help but see the parallels with IT development. The last few shops I've worked in (with one exception) have had Business Analysts, System Analysts, Technical Architects, Senior Java Developers, Junior Java Developers, Product Managers, Software Project Managers, HTML developers, Art directors, DBAs, QA managers, QA testers, Release Engineers, etc. etc.

As a result, even the simplest project ends up involving at least 10 to 15 people. If you then consider the communication overhead this introduces, there's not much wonder that productivity suffers. The funny thing is that all these shops actually think that they're agile.

Anyway, back to the database group's requests for change. WTF!? I've long since come to the view that the database model and the object model are just two perspectives on the same thing. But in a lot of circumstances I see the DB design and the object model design begin to drastically diverge as the product evolves. And naming conventions tend to be the worst offenders.

Usually a glossary of terms is developed (even informally) as the dev team and the business people talk about the business problem, and usually the object model's class, attribute and method names are changed to better reflect the real world problem space. But for one reason or another, the database is left to decay. And then when the all-knowing database group comes along to make the problem worse and suggests/enforces naming conventions, I just give my head a shake...

For me it's all this skill specialization that is destroying the holistic view of the software systems that we build. Smaller teams of people with a broader set of skills and responsibilities are what we need to get the job done.