Comment On Doomed from the Start

Shoot the messenger! It kind of figures with that sort of management.

i was almost the fist post but i had to go to a meeting :(

"You'll be our first real sysadmin maintaining some stuff that a bunch of consultants set up."

Warning sign right there.

Hahahahahahaha damn.

...learned that he was blamed for all of the database's problems.

Well, duh... isn't that standard procedure everywhere? Same as the team member who misses the meeting gets volunteered to organize the Christmas decorating.

In his interview, did he ask any questions about what the job would entail? This is often done.

The last person to touch it is the one who broke it - sounds perfectly normal, to me.

This is... it's worse than worse than failure. I can't even imagine how he faced the horror of each day. Mondays he probably had trouble doing anything that got him from the safety of his bed to the nightmare of his office.

ALTER TABLE?

What the hell are they doing, storing client data as column names?

The thing about assigning blame is that it continues to be assigned until the problem is fixed.

If the company hires a new sysadmin and everything runs smoothly, then perhaps Sergey was in over his head, as a different sysadmin was able to get things working.

If the company hires a new sysadmin and everything remains borked, well sooner or later they will figure out that the problem extends beyond the sysadmin position.

Either way, I cannot for the life of me figure out why IT employees are so passive. Sergey was in meetings with management every single day - if there were problems he was being asked to fix that extended beyond his control, he needed to aggressively communicate that to the right people.

Even if they never believed him, it was still his job to try.

If you start a job and on the first day you learn that you are expected to answer to everyone in the office, run away.

I liked the picture. Seems to describe how some of us might feel sometimes. And along with a previous comment, Come On ! How can the database structure need to be changed every day ? Especially a database that held critical data that everyone used.

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

I'm interviewing right now, and one of the things I'm looking for is a candidate who ask questions about the company, the people who work here, the environment, specific tasks, tools, technologies, etc.

I won't even consider a candidate who is not interested enough to ask those questions. They might be the best talent I can find, but we might not be somewhere they want to work. That needs to be sorted out before they start working here.

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

Haven't you ever seen a RAID inexpensively arrayed? (A ray of light appears...)

The preceding is courtesy of the Department of Unnecessarily Redundant Repetition Department.

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Obligitory quote.

Peter: “The thing is, Bob, it’s not that I’m lazy. It’s that I just don’t care.”

Bob Porter: “Don’t– Don’t care?”

Peter: “It’s a problem of motivation, alright. Now, if I work my a*s off and Initech ships a few extra units, I don’t see a dime. So where’s the motivation? And here’s something else, Bob. I have eight different bosses right now.”

Bob Slydell: “I beg your pardon?”

Peter: “Eight bosses.”

Bob Slydell: “Eight?”

Peter: “Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That’s my only real motivation is not to be hassled. That and the fear losing my job. But you know, Bob, that’ll only make someone work just hard enough not to get fired.”

FredSaw:

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

Haven't you ever seen a RAID inexpensively arrayed? (A ray of light appears...)

The preceding is courtesy of the Department of Unnecessarily Redundant Repetition Department.

I found a bumper sticker that says "Help Stamp Out and Abolish Redundancy"

CAPTCHA: pinball! Booyah!

gabba:

In his interview, did he ask any questions about what the job would entail? This is often done.

The other staff (bosses) didn't understand the role, except that they needed it.

Same response to those who said he should stand up for himself - he was speaking a different language. Someone older and more experienced would figure out how to describe the problem in terms of business risk instead of technology, but still, blaming the consultants looks a bit too convenient for a new guy when there's no other technical staff to agree with him.

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

You haven't been in the enterprise world long enough. A RAID array is a bunch of bottom basement RAIDs hooked up to the same bottom basement PC. In a company I just visited that meant: 5 1TB Buffalo RAID enclosures hooked to an eMachines mini tower. Aka, the ERP storage array.

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Apply an arbitrary list of actions to a list of customers: each action is a column. Each action may only be applied to one or more customers. Since you don't know what actions might be needed, or how many actions, change the DDL.

Of course, you could do this in memory. Or a temp table. Or with joins...

lelitsch:

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

You haven't been in the enterprise world long enough. A RAID array is a bunch of bottom basement RAIDs hooked up to the same bottom basement PC. In a company I just visited that meant: 5 1TB Buffalo RAID enclosures hooked to an eMachines mini tower. Aka, the ERP storage array.

So would that be a RAIRAID? (Redundant Array of Inexpensive Redundant Arrays of Inexpensive Disks)

anon:

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Apply an arbitrary list of actions to a list of customers: each action is a column. Each action may only be applied to one or more customers. Since you don't know what actions might be needed, or how many actions, change the DDL.

Of course, you could do this in memory. Or a temp table. Or with joins...

or with a properly normalized schema. No sane database layout requires ALTER TABLE for operational crap.

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Adding to an Enum field?
Other than that I'm all out. Even then if it needs to be tweaked on anything like a regular basis - the field should be a reference to another table holding IDs & the Enum value.
Also, if it takes 8 hours to run a backup, they should be looking into doing daily transaction captures with weekly (weekend) backups. Trying to run an 8 hour backup everyday with the posibilaty of an 'ALTER TABLE' going off is pretty stupid. Preferentially, I would probably try replication & pause the replication process while I did the backup from the duplicate, then let the process fill in all the transactions that happened while it was backing up.

newfweiler:

lelitsch:

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

You haven't been in the enterprise world long enough. A RAID array is a bunch of bottom basement RAIDs hooked up to the same bottom basement PC. In a company I just visited that meant: 5 1TB Buffalo RAID enclosures hooked to an eMachines mini tower. Aka, the ERP storage array.

So would that be a RAIRAID? (Redundant Array of Inexpensive Redundant Arrays of Inexpensive Disks)

I kind of prefer the 'I' standing for 'Independent' like it was supposed to before the marketing droids crapped on it and attempted to retcon the term.

And we all know that the V in DVD stands for Video.

Franz Kafka:

anon:

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Apply an arbitrary list of actions to a list of customers: each action is a column. Each action may only be applied to one or more customers. Since you don't know what actions might be needed, or how many actions, change the DDL.

Of course, you could do this in memory. Or a temp table. Or with joins...

or with a properly normalized schema. No sane database layout requires ALTER TABLE for operational crap.

or perhaps they decided that consistent database structure is too damn inefficient? no?

newfweiler:

lelitsch:

gary k:

trouble with his RAID array? not to be grammar police, but isn't that kind of redundant (get it?)

You haven't been in the enterprise world long enough. A RAID array is a bunch of bottom basement RAIDs hooked up to the same bottom basement PC. In a company I just visited that meant: 5 1TB Buffalo RAID enclosures hooked to an eMachines mini tower. Aka, the ERP storage array.

So would that be a RAIRAID? (Redundant Array of Inexpensive Redundant Arrays of Inexpensive Disks)

Have you priced those things?
It might be a RARAID, but it certainly wasn't a RAIRAID.

dlikhten:

Franz Kafka:

anon:

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Apply an arbitrary list of actions to a list of customers: each action is a column. Each action may only be applied to one or more customers. Since you don't know what actions might be needed, or how many actions, change the DDL.

Of course, you could do this in memory. Or a temp table. Or with joins...

or with a properly normalized schema. No sane database layout requires ALTER TABLE for operational crap.

or perhaps they decided that consistent database structure is too damn inefficient? no?

Did you miss the part about the queries timing out? Normalizing a database can very well make it run faster.

The ONLY reason I can think of an application to be issuing ALTER TABLE commands is if that application's job is to create schemas and alter database structures. And they have database tools to do that for you.

That part alone is the real WTF of this story. The rest is just filler :)

SomeCoder:

The ONLY reason I can think of an application to be issuing ALTER TABLE commands is if that application's job is to create schemas and alter database structures. And they have database tools to do that for you.

That part alone is the real WTF of this story. The rest is just filler :)

Maybe he is doing something very stupid like creating a table just to store some results in it.. dropping the table once he's done. Real dumb if you ask me, but that is the only reason I can think of.

Quinnum:

I kind of prefer the 'I' standing for 'Independent' like it was supposed to before the marketing droids crapped on it and attempted to retcon the term.

Patterson, Gibson and Katz of UC Berkeley invented and defined the term "RAID" using "inexpensive" (contrast "SLED"). Your preferred term is technically inaccurate; the disks are hardly independent since, by definition, they are taken together to constitute the array.

I find it interesting that you have problems with using the original and proper definitions of these acronyms, but no problem at all, apparently, with the dubious words "retcon" and "droid".

No offence meant, of course--I'm just pedantic.

Actually, I can think of a reason that has been discussed in the past on this very board:

The client side application includes a (runtime defined) number of flexible data entry forms. Which specific fields appear on the forms varies from form to form, and can be changed at runtime.

This leaves you with two bad choices for database implementation:

1)Create table [Data]
(
[ID] int identity(1,1),
[Form] int not null,
[Field] varchar(500) not null,
[Value] varchar(7000) null
)
2) Create (at runtime) one table / form with one column per field [prompting the user for the correct SQL Server datatype for each field], and if fields are added or removed modify the schema using DDL.

#1 is bad because it makes reporting very difficult, at best. Yes, you can (and will have to) pivot the data out for reporting purposes, but the pivot operation itself is both complex (especially if you want the correct types on the columns) and expensive (both in terms of designing it and updating the output tables).

#2 requires the client application to perform DDL, but... Isn't that /appropiate/ if the nature of the data stored in the database changes? That's what would happen if the applicaiton required developer intervention to add a new form / field, after all.

I currently support (and have implemented in the past) several applications that follow strategy #1, and it is real pain on the reporting side. Is it painful enough to convince me that #2 is better? I'm not sure -- it really comes down to how often new forms are added / altered. If the changes are fairly rare (monthly), I'd definately go with the DDL solution to make the modifications "on the fly". If changes are frequent (or indeterminate), I'd look to setting up a seperate development enviroment (where changes are made on the fly), then batch up the changes nightly / weekly to push to production.

Sure; they had hired a ritual scapegoat. This makes them happy. And it's been happening all around, since the beginning of the days. I would suggest not to worry about it, but just enjoy the show.

dlikhten:

Franz Kafka:

anon:

Joshua Norman:

I want to know this myself. Admittedly I only spent a few minutes thinking about it, but I can't think of a single valid reason for any client program to be using ALTER TABLE. Is there one at all?

Apply an arbitrary list of actions to a list of customers: each action is a column. Each action may only be applied to one or more customers. Since you don't know what actions might be needed, or how many actions, change the DDL.

Of course, you could do this in memory. Or a temp table. Or with joins...

or with a properly normalized schema. No sane database layout requires ALTER TABLE for operational crap.

or perhaps they decided that consistent database structure is too damn inefficient? no?

Indeed, that's why I always store my data as XML blobs.

FredSaw:

...learned that he was blamed for all of the database's problems.

Well, duh... isn't that standard procedure everywhere? Same as the team member who misses the meeting gets volunteered to organize the Christmas decorating.

Blaming everything on the last person to leave is a long-standing tradition at my current workplace.. Everything from a production server going down to running out of milk for the tea.

It'll all be my fault in a couple of weeks!

Sergei's experience is a template for entire classes of management antipatterns.

lol

What you are saying is that there aren't any business processes defined, right? Or at least that none are enforced? How else can there be "flexible data entry forms"? I can't see how you can have this kind of "flexible". Sounds like pudding. Not even tapioca.

Captcha: quake...that's what I'd be doing.

Maosn:

Actually, I can think of a reason that has been discussed in the past on this very board:

The client side application includes a (runtime defined) number of flexible data entry forms. Which specific fields appear on the forms varies from form to form, and can be changed at runtime.

This leaves you with two bad choices for database implementation:

1)Create table [Data]
(
[ID] int identity(1,1),
[Form] int not null,
[Field] varchar(500) not null,
[Value] varchar(7000) null
)
2) Create (at runtime) one table / form with one column per field [prompting the user for the correct SQL Server datatype for each field], and if fields are added or removed modify the schema using DDL.

#1 is bad because it makes reporting very difficult, at best. Yes, you can (and will have to) pivot the data out for reporting purposes, but the pivot operation itself is both complex (especially if you want the correct types on the columns) and expensive (both in terms of designing it and updating the output tables).

#2 requires the client application to perform DDL, but... Isn't that /appropiate/ if the nature of the data stored in the database changes? That's what would happen if the applicaiton required developer intervention to add a new form / field, after all.

I currently support (and have implemented in the past) several applications that follow strategy #1, and it is real pain on the reporting side. Is it painful enough to convince me that #2 is better? I'm not sure -- it really comes down to how often new forms are added / altered. If the changes are fairly rare (monthly), I'd definately go with the DDL solution to make the modifications "on the fly". If changes are frequent (or indeterminate), I'd look to setting up a seperate development enviroment (where changes are made on the fly), then batch up the changes nightly / weekly to push to production.

Zemyla:

ALTER TABLE?

What the hell are they doing, storing client data as column names?

Yep. I worked for a place like this. When the customer wanted some new bit of data, they'd end up squirting out some ALTER TABLE statements. My bosses had a thing against Entity-Atribute-Value type data arrangements. Something about "the joins are terrible" yet they'd pretend not to notice that their own homegrown framework would spit up nested views about 20 levels deep, joining the main tables to themselves about 10 times. And since regenerating indexes on these huge tables would take the database out of use for hours, they chose to never use indices. Performance blew for every-day actions, so they'd wrestle with caching.

And since they didn't understand this framework very well, I'd routinely piss them off by asking "who wrote this?" My boss always tried to look wounded when he'd admit that he did.

Jon:

I found a bumper sticker that says "Help Stamp Out and Abolish Redundancy"

URL

doomed more:

What you are saying is that there aren't any business processes defined, right? Or at least that none are enforced? How else can there be "flexible data entry forms"? I can't see how you can have this kind of "flexible". Sounds like pudding. Not even tapioca.

Well, there is at least one company that isactually selling a product that provides the same type of "flexible data entry" that you are talking about, and they have an impressive client list (Serena, with their TeamTrack product: http://www.serena.com/products/teamtrack/index.html. While it isn't clear from the web page, I can assure you that all the data entry fields are end-user defined, as showing this functionality off was 80-90% of the demo that I attended. I don't know exactly how this is implemented, though.

Over and beyond this, if you are a small to medium size company with minimal (or no) programing support available on the payroll, it is highly desirable to have an applicaiton that you can add or remove a field without hiring a consultant to make the modifcaiton.

<shrug>

If you work in a place where all the data entry requirements are static and never change (or, at least, change very slowly with a devlopment team on hand to make changes), then that's great -- but that's pretty unusual in my expereince.

http://en.wikipedia.org/wiki/RAS_syndrome

I was unfortunate enough to work somewhere that used Serena for version control. They could only have 2 users, which I suppose was their own fault for not buying licenses, but the software wouldn't let them change names so I had to be "Lisa" to the versioning system. You couldn't commit from a unix box unless you NFS-mounted the serena home on the windows box, and if that unappetizing solution didn't appeal to you, there was a seriously broken mozilla java applet client. Support, of course, didn't.

It was kind of exactly what using version control is like, except that it doesn't work. I can't for the life of me understand why anyone would pay for something so wildly inferior to free and universal solutions like CVS, SVN, and others.

bch:

If the company hires a new sysadmin and everything runs smoothly, then perhaps Sergey was in over his head, as a different sysadmin was able to get things working.

Or perhaps Sergey had made a big enough dent in the problems that it was a breeze for the next Sysadmin to pick up where he left off and finish the changes

bch:

Either way, I cannot for the life of me figure out why IT employees are so passive. Sergey was in meetings with management every single day - if there were problems he was being asked to fix that extended beyond his control, he needed to aggressively communicate that to the right people.

I fear the day you escape from the sheltered life in which you have lived lo these many years; your head will simply implode from the inaniety of a real-world existence. Believe it or not, it can be quite difficult to aggressively communicate with the right people when everyone is under the impression they are your boss, or worse, when the person who is your actual boss refuses to listen and instead refers you to the psuedo-bosses.

Imagine, if you will, explaining to your boss, an Office Manager, the GM, two VP's and your staff, that it's a bad idea to buy 5+ year old computer equipment, including laser printers, at auction (issues with lack of warranty, repair costs, parts availability, etc.). Fast forward the day of the auction and repeated reminders to not buy computer equipment, to the point of asking your boss to be allowed to attend the auction to help interfere with that eventuality. Then attending the auction and again, reminding the Office Manager not to bid on equipment, just furniture, then watching the Office Manager bid on every printer and Computer lot that came up, winning enough equipment to supply the current needs of the office.

Fast forward 6 months; every PC is either broken or been replaced for performance reasons, the printers are now failing on a monthly basis and you, the IT person who VERY aggressively communicated all of the issues prior to purchase, are at fault for 'not maintaining the equipment properly' and causing considerable downtime. Oh, and to top it off, when suggesting that the downtime could be avoided with new equipment purchases, being told that retiring equipment is not in the budget, we only replace items that are broken.

So, bch, all of your armchair quarterbacking is no substitute for exposure to the real world, where you would quickly come to realize that your misguided fantasies are like competitors in the Special Olympics... just fucking retarded.

bch:

Even if they never believed him, it was still his job to try.

Really, you're new here, aren't you?

pitchingchris:

SomeCoder:

The ONLY reason I can think of an application to be issuing ALTER TABLE commands is if that application's job is to create schemas and alter database structures. And they have database tools to do that for you.

That part alone is the real WTF of this story. The rest is just filler :)

Maybe he is doing something very stupid like creating a table just to store some results in it.. dropping the table once he's done. Real dumb if you ask me, but that is the only reason I can think of.

That's why God invented temp tables (#MyTempTable in MSSQL) :)

Steve:

I was unfortunate enough to work somewhere that used Serena for version control. They could only have 2 users, which I suppose was their own fault for not buying licenses, but the software wouldn't let them change names so I had to be "Lisa" to the versioning system. You couldn't commit from a unix box unless you NFS-mounted the serena home on the windows box, and if that unappetizing solution didn't appeal to you, there was a seriously broken mozilla java applet client. Support, of course, didn't.

It was kind of exactly what using version control is like, except that it doesn't work. I can't for the life of me understand why anyone would pay for something so wildly inferior to free and universal solutions like CVS, SVN, and others.

I had asked the same question of someone, and they said that their company won't use OpenSource or free software, as they are afraid that they won't get support with it. A lot of enteprises are like that, they would rather pay money, and expect to get some sort of support (although that usually costs even more money), and they're clueless that peer based support is load better then enterprise support, and open source software has less bugs and has them fixed faster.

FIST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111!!!11

b0bg0ats3:

FIST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111!!!11

I'd guess you're quite experienced at fisting.

Speaking of Serena TeamTrack, at work I currently use Merant Version Manager + Merant Tracker which were bought by Serena. When we needed to branch for Maintenance and allow for forward development. We spent weeks talking to moronic support people, until we let them know we won't be renewing our contract for the Version Manager software. That is when they told us that they had a newer version of the software. Also they would get their expert to tell us like it is. He solution was one buy the server software (ok) and copy the current database, because the software didn't branch well. This is what they did with the software themselves at the office and it wasn't so bad. So the only highlight from this experience so far is now we are bringing in subversion but they already bought TeamTrack so we are stuck with that.

So the moral of the story is ...
If you hear Merant or Serana when you ask about Tools, I sincerely hope you do, used at a prospective job, remember the job market is good and find a better job.

Steve:

I was unfortunate enough to work somewhere that used Serena for version control. They could only have 2 users, which I suppose was their own fault for not buying licenses, but the software wouldn't let them change names so I had to be "Lisa" to the versioning system.

Well, at least you didn't have to be "Bart."

The concept of "using" a self-modifying "product" for "version control" -- sorry about the qualifiers; I just can't think of it any other way -- is making my brain fry.

I've worked with packages that allow you to modify the DDL before, but the sane ones do this for a reason: namely, to allow you to overlay your own business rules. I wouldn't say it's a great solution; in fact, I think it stinks. It's a perfect example of a supposed "database-centric" solution that avoids actually having to do anything difficult, like coding. Or thinking. Or producing your own database from scratch. But at least the sane versions of this idea have things like access control to the DDL, and hopefully a very restrictive GUI that gives you a blow-by-blow commentary on quite what you're fucking up.

Plus which, normal use would only require occasional changes for specific business reasons, and probably even then only at down-time, like weekends. Dropping tables in the middle of a backup is so clearly insane that a caveman should be able to explain it to his bosses/co-workers.

caffeinatedbacon:

Fast forward 6 months; every PC is either broken or been replaced for performance reasons, the printers are now failing on a monthly basis and you, the IT person who VERY aggressively communicated all of the issues prior to purchase, are at fault for 'not maintaining the equipment properly' and causing considerable downtime. Oh, and to top it off, when suggesting that the downtime could be avoided with new equipment purchases, being told that retiring equipment is not in the budget, we only replace items that are broken.

<church lady>So, you were VERY aggressive .. how nice. And you had a lead-time before the auction to realise that your company was the spawn of the devil? And it took you six months to listen to God, to write your resume, and to apply for another job? You do know that you're afflicted with deadly sins 4 and 5, and probably 7, don't you? (Dances superiority dance.)</church lady>

caffeinatedbacon:

So, bch, all of your armchair quarterbacking is no substitute for exposure to the real world, where you would quickly come to realize that your misguided fantasies are like competitors in the Special Olympics... just fucking retarded.

Cute.

Just ... cute.

Whoops, guv'nor, I lost me leg. I have to resign from my post as the National Coordinator of Transport Policy because I'm clearly retarded. Sadly, I am now "Special."

Or:

Whoops, guv'nor, I had half me brains blown out by an IED whilst serving in Afghanistan. But that's OK. If I'm to run the 400 metres in the Special Olympics, I want a big sign on my back that says "I'm not just retarded. I'm fucking retarded!"

Or:

Whoops, guv'nor, I was born with cerebral palsy ...

You get the idea.

I'm trying not to be simply politically correct here, but, to be perfectly honest, people like you make me sick to my stomach.

(For anybody who wishes to disagree with this sentiment, please first note the presumably unconscious association with "misguided fantasies" in the same sentence.)