The Old Joel on Software Forum: Part 3 (of 5)

Role Fragmentation

Good article:

http://www.softwarereality.com/lifecycle/role_fragmentation.jsp

The "Database Administration" section echoes one of the recent JoS threads about DBAs:

"I understand that those DBAs who understand the details of the database engines are worth their weight in gold. They are in essence developers, human like the rest of us.

However, there are a large number of DBAs who don't understand databases. Their position of authority comes only from them holding onto the database permissions. Any thought of creating or altering a table on even the most prototype of system is firmly resisted. Before you can create a table, it must pass the unwritten naming standards convention. Table names must be upper or lowercase, abbreviated so that they are unreadable and match the mainframe naming conventions of a maximum of 8 characters."

Portabella
Monday, December 8, 2003

Why don't we just shoot the jobless, turn them into dogfood, or export them to the 3rd world? :-)

Frederic Faure
Monday, December 8, 2003

> Why don't we just shoot the jobless, turn them into dogfood, or export them to the 3rd world? :-)

Sounds like a business opportunity to me!

We could call the company "Soylent Green".

Mr Obnoxious Man
Monday, December 8, 2003

We're in business, partner :-)

Frederic Faure
Monday, December 8, 2003

I have to suspect that if you shoot the jobless, you'll kill the article's author. He sounds a tad bitter to me...

Kyralessa
Monday, December 8, 2003

"Is this good for the company"? :-)

Frederic Faure
Monday, December 8, 2003

You might want to try Germany; I hear there they've got people _volunteering_ to be Soylent Green.

Kyralessa
Monday, December 8, 2003

Refering to the guy who wrote a personal to be killed and eaten up? :-)

Frederic Faure
Monday, December 8, 2003

The company theme song:

http://www.lyricsdomain.com/4/dead_kennedys/kill_the_poor.html

Mr Obnoxious Man
Monday, December 8, 2003

Nice article.

>> If the trend of administration continues then most projects will not be cost effective. It's no wonder that so many projects are being outsourced.

Yup. It sounds like union "featherbedding" of the railroads: creating nonsense jobs just to increase head count.

That's why I couldn't be more gung-ho toward the guy who started the thread here about doing "soup to nuts" project roles. Companies increasingly think they only need narrow specialists, so being obviously multifaceted is a distinct liability in some (many? most?) environments.

Bored Bystander
Monday, December 8, 2003

Yes, I too enjoyed reading the article, but it seems like my reasons for liking it are different than the JOS readers who have already posted to this thread.

Personally, I thought the comments about the article were a lot more interesting to read. The reality (to me at least) is that just about every corporate IT department is a complete mess and the problems these departments are encountering are only getting worse.

The only part of the article where I totally agreed with the author was when he mentioned how it seemed like many software vendors are concocting software development job roles out thin air. Note: I am not saying that any particular job role isn't needed or that the work these imaginary employees do doesn't really need to be done -- my only criticism is who can afford to pay for all of those bodies?

Btw, many System Development Lifecycle (SDLC) methodologies seem to do the same thing. Some of this can probably be explained away as -- the author(s) has a secret agenda (to sneak more billable employees onto the project). Even so, I do believe there are situations where the project work really is so complex and plentiful that the overhead of hiring many specialists is justifiable.

One Programmer's Opinion
Monday, December 8, 2003

As a contractor I've noticed this trend too. Ten years ago the sys admin was there to look after the unwashed, and didn't dare touch developers machines.

Then, a couple of years ago I worked at a place where the developers were always worried the sys admins, during one of their nightly checks and updates, would wipe out valuable work, if not delete installed tools. They were like fascists.

At the latest place, the sys admins wouldn't give anyone privileges above user, even developers. You had to ask them to install stuff. Because of this policy, everyone always needed the sys admins to do anything, so there was always a big backlog of work for the sys admins.

The sys admins could curry a lot of favour in this arrangement, because they would give priority service to general managers and so on.

JM
Monday, December 8, 2003

I work for a large university as a programmer. I will say that I've met good admins and not so good admins but the *policies* set by *committees* are the cause of the problems, not necessarily the admins themselves. Somewhere sometime the “Data Administration” group said that all database tables in our environment should be off-limits (e.g. I can’t select from them), no matter what the contents. In order to get access to specific tables I have to go through a long (three or four business days) and ultimately silly process to get them added to my login. Note that there are generally no questions asked and I’m never denied – so why not just give me access to everything instead of me having to ad hoc request specific tables? No one can answer other than “that’s the way it is”.

Previously I worked at a number of other software companies (private sector) as both a programmer and DBA in which they were much more relaxed. They trusted me not to break things and I didn’t. I didn’t have root to the database server machines, but I did have ‘sa’ and didn’t abuse it. As DBA I didn't really care what programmers did, but I did require that new tables/alter tables/indexes/etc. went through formal processes first.

The problem is that the educational process here in the US (and really everywhere) for computer science is not... very good. :) As a DBA I couldn’t grant ‘God’ access to programmers nor could I let them make schema changes because they didn’t prove to me that they knew what they were doing. Examples on this board haven’t changed my opinion much (look at the number of threads on ‘how to do XYZ’ and the multitude of different replies, most of which are wrong!)

When I came on board the developers only had a very cursory introduction to database design and little/no normalization – so they’d want to do stupid things like create big varchar columns and stuff them with comma delimited values, or index every column on a table, and perform joins in application code, etc.

Liberal use of the clue-stick and some re-training from myself helped evolve them to a much higher level and I was able to grant them higher privileges. Database design is not something you can sit down and fake without education.

MR
Tuesday, December 9, 2003

INSTITUTIONAL KNOWLEDGE can't be outsourced

If a generalist understands the COMPANY that all of the software (or IS/IT "assests") are serving, this is unique knowledge which can't be outsourced.

I.e., if you're implementing electronic medical records (EMRs) you might outsource low level coding, but if the IS adminstrator *understands* how the Physical Therapy department is going to use actually USE the software on a daily basis, because s/he understands how that deparment works, then that's valuable and can't be outsourced.

I know one large hospital in the northwest that needed a liasson between the developers and the users. Someone who understood the needs of the user and the capabilities of the program. They found it easier to teach a medical person the interface (menu) design that the other way around.

This intersection between the technical and the human is where we can have the biggest impact, the most value addeded, and the least likelihood of being outsourced to India.

Entreprenuer
Tuesday, December 9, 2003

From the article:--"Another great idea borne of lack of experience is that of roaming profiles. It may be OK for lightweight users who pull single files off a file server then replace them. Back in the real world, I need my megabytes locally."---

Err, nothing to do with roaming profiles (unless you're stupid enough to keep your source safe on the desktop). All to do with keeping data on a network directory as opposed to a local drive. Want your megabytes locally? Try drag and drop!

Stephen Jones
Tuesday, December 9, 2003