Naming convention WTF
-
We have a client with a SQL-backend accounting package (customers, vendors, inventory, orders, financials). By default, the database is named X, but you can change it; we used X_prod for the production DB and X_test for the test DB. This has worked well for a couple years now.
Last week, I moved their production DB to a new server, and the in-house IT guy redirected all the workstations to it. Surprise surprise, we discover a few quirks after the fact, including another SQL-backend package Y which interfaces EDI with X; turns out it needs to be on the same server as X, so we have to move it, too. We've only ever been peripherally involved with Y, and the in-house guy is no expert either (it dates back to at least one of his predecessors), but its databases are named Y_prod and Y_test, so I move Y_prod and he goes off to test it.
It doesn't work, and we start digging through variables, encountering several red herrings. Finally, this morning, I find that Y_test had actually been used for production work, and Y_prod for testing if anything (it had only seen six logins in two years prior to last week's move).
-
Yeah, we had a simelar problem here about a year ago. We have a large, internally developed web-app that handles financial tracking for a Government service, managing about $30 million a year.
We had a contractor come in to make a few minor upgrades to the system. (Management WTF number 1, you've pulled your entire internal development team onto one project, so you hire in contractors to handle your basic maintenance??).
This contractor did the work, it all worked fine in test, he submitted his change control documentation and was given approval to follow the steps in the change control documentation to push the system live. (Management WTF number 2: Why was the contractor given access to publish content into productino?)
Two months later, we start getting complaints that the latest data was not appearing in the end of month reports, and the system keeps falling over. Upon investigation, we discover that the system was running off the development server. Apparently the contractor had skipped step 8, changing the configuration to point to the production database. This system had been running off the development server for the last 2 months.
As you can imagine, there was a LOT of work involved in sorting out all the data and pulling the two systems together again. (Auto-incrementing numbers for the primary keys of tables).
I really really hate that our managers always tend to trust the contractors more that the internal staff (huge cultural issue in my workplace).
-
@grassfire said:
...I really really hate that our managers always tend to trust the contractors more that the internal staff (huge cultural issue in my workplace).
"<font size="5">T</font>rust no one, double check everything," That's my motto. Mr. Peer Review.
-
@grassfire said:
I really really hate that our managers always tend to trust the contractors more that the internal staff (huge cultural issue in my workplace).
Try every workplace - it's a cultural thing in general, external contractors are trusted more than in-house staff because in a manager's eyes 1) they cost more and must therefore have more valuable opinions, 2) in-house staff are close to the project(s) and therefore not impartial.
Since getting into IT management I've had to try really hard to remember why I need to trust my staff above any outsiders, and it's paid off more than once.
-
Well, our clients trust us, but that's built on demonstrable results and long-term relationships; hiring contractors out of the blue and trusting them just because they're contractors is indeed a WTF. There's also the issue of knowing our limits, as well as the limits of in-house staff (many of whom are just data entry clerks or the like).
-
@emurphy said:
It doesn't work, and we start digging through variables, encountering several red herrings. Finally, this morning, I find that Y_test had actually been used for production work, and Y_prod for testing if anything (it had only seen six logins in two years prior to last week's move).
This probably happened because when they finished testing, they decided to use the testing instance for production instead of copying it to "prod". Which indicates that they were unsure if such a copy would work, but such uncertainities and doubts happen.
