The Daily WTF: Curious Perversions in Information Technology

antoshka · 2016-12-01 Reply Admin

Frist Article Comment

2016-12-01 Reply Admin

And so when the company I worked for decided to digitize the personnel-files. They thought de author field wasn't used in the archiving software. So they used that for identifying which document belongs to who.

In another office of the same company the guys worked by the book and did fill in the author field.

A puzzled colleague of human resources came to my desk asking why her file was so big.

Reusing flags is evil. Having database admins like that who work for themselves instead of the company is beyond stupid.

DocMonster · 2016-12-01 Reply Admin

What is beyond stupid is having to go through some committee to change something when there's a hard deadline set and not be able to actually reach out to them and say hey look this needs to be done

2016-12-01 Reply Admin

That is how system degrades beyond maintainability. Admit the intake procedure is stupid but there are so many solutions to this problem. using an integer field you might have 31 flags to play with without any database change requests.

Steve_The_Cynic · 2016-12-01 Reply Admin

Re: integer fields as bitmasked flag arrays: It makes the queries to select only records that have (or do not have) the flag a bit painful to write, and a bit painful for the poor server to execute.

2016-12-01 Reply Admin

The application needed to be up and running for the first of the month

As every divorce starts with a marriage, each delay starts with a planning.

The biggest problem of our industry is not admitting that setting a deadline for software development is as smart as walking in a shop and declaring what you want to buy and how much you want to pay.

2016-12-01 Reply Admin

That is how system degrades beyond maintainability.

Indeed! It starts with a developer who chooses respecting an arbitrary deadline instead of forcing management to acknowledge the idiocy of a committee and a process they have permitted to flourish.

2016-12-01 Reply Admin

But the integer should be approved anyway by the committee at some point! And, as Steve already pointed out, if the committee has any use, they will reject a field supposed to be queried on but so index-unfriendly.

2016-12-01 Reply Admin

In any sensible development planning you choose between WHAT features you ship or WHEN you ship. One or other of these has to be either flexible or pessimistic to allow for the uncertainty of the processes. If you're sensible you probably look at a plan that includes some mandatory features and some nice-to-haves and plan a timescale that you hope will include most of the optional issues. That way if more time is required for a core feature then this can be accommodated without delaying shipping (within reason), while you don't leave people sitting around doing little by the end. (N.B. I've never worked somewhere that sensible.)

2016-12-01 Reply Admin

The wholeapproval process described here is of course a giant WTF, but the "trick" used to work around it is even worse. This is disaster waiting to happen, because one day someone will decide to upgrade the database to the '90s and drop the Fax column. Goodbye functionality.

The only proper way to handle a situation like this is to tell management that the review system prevents you from deploying at the agreed time, then wait until the dust from the intra-manager fight settles and see who emerges as the victor. Either an exception to the review system was pushed through and yoou can deploy, or you have just gotten approval from management to delay deployment.

The real WTF is fixing (and covering up) other people's sh^H^H problems.

2016-12-01 Reply Admin

Regardless of who "emerges as the victor" it's the OP who gets the boot because he will be found guilty of preventing deploying in time because he couldn't fill out a damn form properly.

2016-12-01 Reply Admin

Worse than failure indeed: nobody wants to fuck up, everybody does precisely what is required, and the result is another article in a few years time. The process itself even has sane ideas behind it.

Lovely.

2016-12-01 Reply Admin

"This is disaster waiting to happen"

Quite so. "Misusing" fields for a different purpose than orignally intended definitely IS a WTF. I complained about how our database is a mess on the last article and I will complain about it here, too. Some columns can hold a date OR sometimes the amount of purchase. And sometimes part of an address. Just because co-workers thought "ah well, I can use this field to store the info, it isn't used anywhere else, right?"

2016-12-01 Reply Admin

Correct Steve the Cynic.

But up to now I have never needed to select records on flags, just show values. If you query them they tend to result in table scans anyway as they only have two values (Set, not set and File not found) and their distribution is bad.

2016-12-01 Reply Admin

"The only proper way to handle a situation like this is to tell management that the review system prevents you from deploying at the agreed time"

And then your immediate manager just puts on their stern voice and says something like. "I don't want to be bothered with this. Add. The. Flag.". With the obvious implication that you'll be the one thrown under the bus if it isn't done. And your manager's manager is hostile to you as well.

I am so grateful I work in a company with decent management.

2016-12-01 Reply Admin

Ah, yes....after 6 years at a large, enterprise-ey corporation (which acquired our successful smaller company) that had an almost identical process for even the most minor changes, our small and agile team ended up pushing EVERY change through as an exception to the review process. The obvious question was, "why was the process still there, if every change we made did an end run around the process?" Our direct supervisor, who never produced a line of code in his life, eventually ruined our entire business model and our entire business "unit" was shut down, scattering our efficient, tight-knit team of 13 years to the four winds... Hmmm...perhaps there's a WTF story in there somewhere?

2016-12-01 Reply Admin

Quite. Several times at a previous gig I tried to make broken processes break things so that the idiotic process would be fixed. Each time someone well-meaning subverted the process, so management continued to believe the process was good.

2016-12-01 Reply Admin

OP is entirely justified. His employer set up that stupid system and deserves every single WTF that results from it. Sorry if I sound jaded but it's very difficult for me to view software development as anything but a train wreck that I have zero control over. You're damned if you do and damned if you don't. Speak up and be fired for being uncooperative or keep quiet and be fired for not cooperating. The only way to win that game is to not play it at all.

2016-12-01 Reply Admin

"That is how system degrades beyond maintainability. .... Indeed! It starts with a developer"

It starts with management. And that allows "those developers" to take hold.

PTSD story: Our app highlighted errors in red but for many users that was all but invisible. The keeper of that bit refused to make that 2-4 character color enhancing change. I end up in the director's office pleading the users' case. He calls in that petty tyrant, asks her. She says no. Director says no. Another management in-breeding program success.

2016-12-01 Reply Admin

<quote>The biggest problem of our industry is not admitting that setting a deadline for software development is as smart as walking in a shop and declaring what you want to buy and how much you want to pay.</quote>

So long as 'how much you want to pay' is greater than the asking price, that works out just fine.

2016-12-01 Reply Admin

Refusal to change a process to accommodate color-blind people is these days a criminal offence in many jurisdictions.

It is little different to people refusing to provide a wheelchair ramp at the front door.

Point out to management that they are breaking the law and it ought to concentrate minds.

"Ought to..."

2016-12-01 Reply Admin

Oh, some time ago I laid my hands on a database where I had to extract data from and put it into modern (sensible) system. The legacy database was fantastic! There was table _jobs that obviously contained information about employees! And there was table job that sensibly contained information about job. Field JobStartDatewas obviously person medical notes. And so on it went. It was a great fun to discover little twisted logic behind all the naming. Only there was no database committee to reject changes - the application that used this database was developed in Dreamweaver by a ... let's say not so-bright non-developer.

2016-12-01 Reply Admin

I have to agree. For one thing, this is the only time he'll ever be able to try this trick -- he's really only kicked the can down the road (that can being the fundamental problem of this ridiculous change management board which functions more as a change rejection board than anything else and which seems utterly incapable of communication). For another, yeah, misusing a field to accomplish this gets him past the deadline but sets him up for potential disaster later.

I wouldn't want to be the one explaining that I decided to abuse the Fax field because I didn't like following the process. Even if the process is stupid, that's a bad answer.

No, what you do is you very clearly raise the issue with your direct manager and all the major stakeholders on this problem. Let them know that the requests are being rejected out of hand and without any regard for the criticality of the requests. I'm all for strong CCB control; I'm a software configuration manager. But this isn't strong control. This is a CCB not doing its job, and the company is suffering as a result. Requests must be considered in a timely fashion, and if they're making no attempt to understand the request nor to adequately communicate the reason for their rejection, they're not doing their jobs.

If, after warning management of the risk, the control board still won't approve the request, you let the deadline pass.

That's the only way you'll get change happening. If the process is hamstringing development and management doesn't believe you, stop pulling off miracles that let them get away with that. Either they need to give you more time, or the board needs to be addressing requests in a more productive manner.

By the way -- they don't allow you to attend the meeting to defend your own request? That's frankly nuts. If they won't allow you to attend, then they take on the responsibility of talking with you ahead of time to understand the request. Obviously they are not doing that. That's on them, frankly.

2016-12-01 Reply Admin

Oh lord -- colors. I had that problem once. One of the leads (who sat on the CCB) was incredibly dismissive of a change request pertaining to the color of some fields due to colorblindness concerns. He flat-out refused to allow the change.

So guess what happened? First customer representative who came to watch the demo happened to be colorblind, couldn't read the text, and asked why we'd ignored the requirements for a colorblind-friendly GUI.

2016-12-01 Reply Admin

So what do you do when you get the DBA request in and it takes too long and there's no time left to develop? Simple, do the DBA work yourself in your own sandbox, test it to hell and back, and tell your managers its ready to go whenever the DBA's are. Then they are killing the timeline not you. Even better, when they screw it all up, you and your manger give them your script and say "Run this you idiots". I actually did this once (with tamer language) after consultation with my IT management and Business Management (a divisional VP). We all thoroughly enjoyed sticking it to them. Naturally they hated me for the rest of my tenure, 8 months, but they had learned they better not screw up or delay any of our Division's requests.

2016-12-01 Reply Admin

No, no, no, no, no! The right way to handle red tape is really letting the bomb blow, even though it is flatly against the interests of the company.

So when the deadline rolls around, the change is not done. The customer is shouting and screaming - and the customer is always right. Then, you can say “I have done what could be done, and here is proof. But I was thwarted by the database committee.” Blame is thus instantly transferred to that committee. They have got to justify the “principles” that were grounds for disgruntling the paying customer. This is very hard because principles are abstract by nature. On the other hand, the bottom line is very concrete by nature. Bosses' bosses don't understand principles, but they understand money being burnt right now. The principles will lose!

In the same vein, whenever missing authorizations prevent you from doing your job, don't try to circumvent the restrictions. Instead, jump through every hook to acquire the authorizations the proper way, and when that predictably fails, then fail at providing the customer service. Then diffidently point out to the powers that this specific red tape specifically thwarted you. The red tape will be cut without further ado, the manager(s) responsible for it will get a sharp rap on the knuckles, and next time around, you have your authorizations.

2016-12-01 Reply Admin

If Gus thought that misspelling Field was grounds for the application to be rejected by the committee, then the effectiveness of the committee should be brought to the appropriate levels of management to correct.

2016-12-01 Reply Admin

After implementing the feature using field abuse, Gus spent the next weeks submitting the change request for the flag until it got through, and then he wrote a migration to move the data from the abused field into the right place. He also started maintaining a list of unused fields that can be temporarily abused until the committee approves the proper changes.

2016-12-01 Reply Admin

Yes, we'll take an integer field, store it as 7-digit BCD, and use the extra nibbles as bit flags, store the phone number as an integer, and wrangle the new "Document Description" into a DateTime field.........

2016-12-01 Reply Admin

CCB is where I sent changes to die ... e.g. customer requests Real changes are just done.

2016-12-01 Reply Admin

Any sensible company is strict on database changes especially in production.

Before production, it needs to be routinely checked but not every change. More like review the differential every week or something like that. Then pre-production a senior database plus business expert should check over everything more thoroughly. The key point of routine checks before that is to not review once thoroughly after 6 months development then have to fix errors made 6 months ago then repeated for 6 months.

Put it this way. You want to grow an apply tree. You don't check your seeds properly though. One year later you return and you realise you've got a pear tree. Damn. One year wasted.

As for these six elders, once upon a time you did have good standards. That meant checking your work first and proof reading it to at the very least eliminate trivial errors. Some of these people had it hard. Making a mistake with a type writer for example meant losing an entire page. They have a sense of that, millennials have a weaker sense of it. In the short run it might not seem like small errors, corner cutting and oversights matter but in the long run it does.

I'm not saying they are not being too strict. Rather that I don't think a case of excessive strictness should be used to justify a lack of strictness. Things like discipline are important. Especially when it becomes impolite, being careless then submitting work down the chain for others to clarify. If someone can't manage something as simple as a spell check which then creates a distraction to others when reviewing the work for more legitimate errors then who knows what else they might overlook. It means that they need even more scrutiny and even more work for others.

2016-12-01 Reply Admin

Continuation...

I've made a lot of WTFs myself in databases or have learnt better ways to do things. Still when I started the quality of my work was good in that it was well thought out, I put in effort to verify things and tried to be as consistent as possible. It only took me a few iterations to start doing things at a high level of quality making good use of database features to ensure data integrity, avoid duplication, the potential for anomalies, to make query writing easier and so on. I still think I could likely improve more when it comes to how I do things but the point is in each iteration I improve significantly, I don't just stick to what seems to work naively.

Today however my life is a misery when it comes to databases. Once they fill up with data you're doomed. It's nearly always other people's work which is substantially worse than my first iteration of relational databases. I only make a few problems, enough that can be fixed, learnt from and that allow progress. What I encounter from legacy systems, I spend 95% of my time dealing with the aftermath of other people's problems. I don't even have time to make my own problems and own solutions. There people create solutions that merely create two new problems. It multiplies until it's all consuming. What it particularly depressing about it, not spilling a drink is much easier than cleaning up a spilt drink. These people are vandals. It's like if someone just went around knocking things over then leaving the mess for someone else to clean up. They spill their drink anywhere without giving a damn and just go get another one.

2016-12-01 Reply Admin

Welcome to software development, where everybody else has free reign to fuck up at will without responsibility while you have to beg for approval of every line lest a committee of assholes dole out another lecture about bracket placement.

2016-12-02 Reply Admin

I'm working on a project where the start date fields have to be either the start or cancel date depending on criteria. I cried a little. They're paying though so can't complain.

cheong · 2016-12-02 Reply Admin

Humm... The following line is directly copied from a project I'm working on:

SELECT ID FROM [dbo].[SOURCEVIEW] WHERE FORMATTYPE & 1 = 1

1 in FORMATTYPE field means this source supports export in Excel format. Not very difficult to do it, right?

2016-12-02 Reply Admin

I worked with a team once in which one of the developers built a cutesy "traffic light" widget for an app we were building: yes, that's right, complete with the Victorian ironwork and all. It indicated progress status, by means of showing the appropriate light as a brighter shade of either red, amber or green. Where's the problem there? Only that when presented with three blobs of colour, it is not obvious which one is the "bright" one and which ones are the "not quite as bright" ones. At least, it's not obvious to a colour-blind person. In our office that happened to be me. I took one look at it and dissed it unmercifully. Consequence: I was then tasked with reviewing all such customer front-end overdesign for colour appropriateness, and the original developer left in a huff for pastures new. The latter was not all sweetness and light, because I was the poor mug who had to take over his (appallingly designed) applications.

Steve_The_Cynic · 2016-12-02 Reply Admin

As you add more bits, it becomes more expensive to write the next one correctly and more difficult to read them (what exactly is that "64" in there? should it be 64 or 32 or 128, or, worse, 4?) and it doesn't become cheaper to execute. As the number of records goes up, the index-less field becomes progressively more and more expensive to query, since the DB server has to look at every record every time in order to do the arithmetic.

2016-12-02 Reply Admin

Scanning all records is a.k.a. a full table scan, which is best avoided. Adding the bit field to the used index allows the scan to work within the index which is still bad but a lot better as the index is more likely to be held in memory.

2016-12-02 Reply Admin

I just wonder why there is a board of DBA's reviewing the developer's suggested changes in the first place - to me it sounds like the DBA's are not doing their job.

In my company, a DBA is responsible for the database, so when a new feature is to be developed, it is the DBA that has to come up with the DB solution that fulfills the requirements and the developer is to implement it. Preferably this solution is done by the DBA and developer working together and agreeing - but no DBA gets to block a feature on my watch without presenting a better solution within the requirements.

2016-12-03 Reply Admin

Here in Telec*m Italia the most abused/misused fields were NO_BILL and FEDERAL_TAX.

Scarlet_Manuka · 2016-12-05 Reply Admin

Then, you can say “I have done what could be done, and here is proof. But I was thwarted by the database committee.”

No, then you get in trouble because you clearly didn't submit your request in a sufficiently timely fashion to allow for the proper approval process.

2016-12-05 Reply Admin

feild looks like failed

2016-12-05 Reply Admin

Only numbers marked with an asterisk can represent actual values. Every other number is a combination of values. No "single value" can have a number that can be achieved by adding together the numbers from other single values. That's how a bitwise value is stored. They are not x2 the previous value. That only works up to 8. It may not be easy to "read" by a user, but a properly implemented bitwise value is always deterministic, otherwise there's no point.

2016-12-06 Reply Admin

Unfortunately if you apply both schools of logic(don't make changes to the structure if possible in case something breaks, and don't go putting things in bitmasks) you eventually wind up with something like what I have seen before.

Someone decided that bitmasks could be replaced with a join table, if the join exists it's a 1, if it doesn't it's a 0, but doing so would create two tables for every bitmask this gets rid of. Not very nice. So they came up with a way to create only three tables.

MasterLink, MasterFlag and MasterLinkType

Want to create a new bitmask for something? It's really easy, add an entry to MasterFlag, take a note of the handle, then create a new MasterLinkType for the tables you're going to be joining "COMMENT__MASTER_LINK_TYPE" and then use these to create entries in MasterLink, it's so extensible, never again will anyone have to wonder what joins onto what because it'll all be in one place.

Unfortunately it means none of these tables has any information without any of the others, and the lack of foreign keys means dead data builds up, but they managed to replace all changes to the database structure for bitflags with inserts and a ton of selects against the same tables over and over again.

I left when management wanted to know why the system had to be down for a few minutes during a migration that introduced a few new text fields(which had to happen, the table was huge and this was back in the days when a new field meant a full table lock and copy) when they were discussing ways to reuse the system to create MasterVarchar and MasterBlob for any new fields to prevent downtime of any kind.

2016-12-06 Reply Admin

".. asking for a new field 2 weeks ahead of when it was slated to go live, just in case"

That makes it sound like it's a lot of time - based on that heavy weight process that was never going to be enough.

2016-12-07 Reply Admin

Just kick it up the tree. Then it becomes Somone Else's Problem, and someone way higher than you will kick DB admin butt & it will get done.

To hell with forms! Just tell your boss he will carry the can if it doesn't get approved

Just The Fax, Ma'am

Leave a comment on “Just The Fax, Ma'am”