- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Frist!
Admin
Hands up, everyone who ever had to mount a TK-50 on a TZ30. Literally the worst experience in my entire 30+ year career.
Admin
Gotta love the avionics industry... Those iron-clad, no-room-for-common-sense rules and processes were a big part of me leaving my job with a big military contractor. My favorite had to be the project where the requirements (from the customer!) specified that we'd write our software in C/C++, but explicitly called out that we could not use any pointers or object-oriented language features. Basically, it was the old "we don't want you to shoot yourself in the foot so we'll take away your gun" argument. And then they wondered why the program ran so slowly when every single function used pass-by-value semantics.
Some good news on that one... I never could convince them that OOP was a good thing but at least they backed off on the "no pointers" stance a bit so that we could at least use them for function arguments.
Admin
"... my boss looked the other way because it saved a lot of time."
There's TRWTF: looking the other way, instead of investing some effort into resolving the issue. If your staff have implemented "unofficial" software that equates to a 100-fold efficiency improvement, then the next thing you do is to make that improvement "official". If I were that boss, I would be moving heaven and earth to do whatever it takes to get someone "officially" working on this tape loader.
Admin
This comment will be approved in 11 hours, but only after the official software has been run. If you see it appear earlier the appropriate authorities will be notified.
Admin
Nearly my thoughts: The company was already broken if they did not manage to improve within 2 years with a proven working solution.
This should be warning enough, hiring a process obedient manager is only a small step further.
Admin
No, TRWTF is the moron that came in and forced a rollback to the time-wasting version. You might have to have worked in a stupid environment to understand why the first boss only looked the other way. Doing it quietly not only solves the problem but, more importantly, allows poor management to save face. These days, though, we don't get the source to these garbage products and can't even try what Snoofle did.
Admin
You can sort of see why a rule of "official programs only" may get created in a security-sensitive environment. The problem is that nobody ever decides what "official" means or who decides what is official and what isn't or defines any processes for making something official!
And then you will always get jobs-worths middle management who insist on just following the rules and upholding the status-quo regardless of any shred of common sense. Partly, I suspect, just to flaunt their limited power and partly for fear of getting reprimanded/sued/executed by their own jobs-worth stupid boss (and without the intelligence to try and sell the case for improvement).
Admin
I'm not quite old enough to have struggled with a TZ30, but I used a TZ86 autoloader on a daily basis. That thing was more than an order of magnitude faster than your TZ30, so I can't even imagine.
Admin
If it's a vendor product, the chances that they will take a customer customized version and make it the official one are zero.
Admin
yes - exactly. one fighter jet falls out of the sky, whether it's caused by your change or not, and the shit is going to hit the fan. CYA
Admin
This calls for a contest. Write a routine which, with bad intent, includes even more "safety checks" and thus runs even longer than the OfficialVersion. Infinite redundancy, and "pause"-type commands are not allowed, but otherwise go for it.
Admin
Yeah, my first real programming job in 93 I had to write buffering into the copy routines because the weird x86 OS they used didn't support disk buffering, and nothing in the C libraries either.
Admin
quote:This calls for a contest. Write a routine which, with bad intent, includes even more "safety checks" and thus runs even longer than the OfficialVersion. Infinite redundancy, and "pause"-type commands are not allowed, but otherwise go for it.
Well that's really easy. After the flush go back and do a read of the byte from tape again (requiring the tape to transport backwards!) and then read the byte from disk, ensure they match. Every 17 bytes (or whatever the disk sector+1 size is) do a second validation that ensures that the block was written correctly; starting on the last byte of the previous sector to verify no issues happened on the sector boundary...
Should bring it to it's knees all with the very valid: We've got to be sure
Admin
Learn something new every day. The oldest tape storage technology I ever knew (but never used) was the cassette tape, which required a constant stream of data available, and figured that even the purpose-built drives were the same way. But apparently in the olden days, tape drives were designed around stopping and starting. Still... byte at a time?
Modern tapes would be shoe-shining and maybe even writing tape marks with each flush(). That would be inefficient, cause wear on the cartridges and the drives, and be all-around horrible. Even with their internal buffering.
Admin
THIS.
I work in this industry. There are actually very good reasons for requiring only officially sanctioned software to be used. And if the company isn't completely incompetent, a situation like this translates into "hey, we need to fix this". You never use unreleased software in a production environment. If the released and approved software is crap, you get it fixed and get the fix released and approved so you can use it.
11 hours to a few minutes? That's a huge improvement. Where I work, a full software release typically costs about 20 hours, including regression testing and all the signoffs and reviews and approvals, and that's for software that's much more complex than this thing sounds.
Seriously, how much effort does it actually take to release a new version of the software? Even if for some bizarre reason, the contract specified a very specific version of the bootloader, the ECP to cover revising the software would pay for itself. The only possible reason I can see a company refusing to bring this to the customer's attention is to increase their billable hours. After all, the OP taking 11 hours means they're billing 11 hours, and they get a cut of each of those 11 hours. That's the only remotely rational explanation I can come up with.
Admin
"You can sort of see why a rule of "official programs only" may get created in a security-sensitive environment. The problem is that nobody ever decides what "official" means or who decides what is official and what isn't or defines any processes for making something official!"
It's not just security. It's also quality and reliability they're concerned about. You gotta know where everything came from, so if something goes wrong, you can figure out why and fix it.
And if there's no process for making something official, that's possibly an even bigger problem. It would mean inadequate configuration control. Where I work, it is very clearly defined -- at minimum, it has to be formally released in our configuration management system, and additional requirements may apply depending on the specific situation. These are always clearly documented, for instance, with a bill of materials or a verified system configuration or a detailed procedure.
Admin
My first job was as a "field maintenance programmer" on an air defense system. The programs were written in a 3GL; ok, not exactly. The data structures were defined in the 3GL, but the code itself started with the "direct" statement, which told the compiler that what followed was assembly language. The particular 3GL had nice data-defining facilities, and the assembly code had features which let you use them.
There were concerns that the compilation process could create incorrect code, so any change to the source required full regression testing. For maintenance releases, we would in effect create patches to the executable; this was considered safer since it was apparent which sections of the code had changed.
Admin
I really LOVE that snoofle is now sharing his stories. I'm starting to open thedailywtf with a secret hope it's a new one. There could be a section of "stories from the editors" for this kind of articles.
Admin
Yes, there was a lot of stopping and starting. Those big cabinets the old tape drives had were there so that the tape could hang down in a big loop. The loop would absorb the strain that would otherwise be put on the tape by the reels stopping/starting. Which they could do a lot.
Admin
"And if there's no process for making something official, that's possibly an even bigger problem" It casts doubt on the provenance of everything that's already "official" - how did it get that way?
Admin
TIL why those tape cabinets were so big. cool factoid.
Admin
" It casts doubt on the provenance of everything that's already "official" - how did it get that way?"
I'm going to guess that a lot of investment money was poured in to start, with developers (or Highly-Paid Consultants) brought in to write the software and QA it. Or maybe it was even off-shored to people who learnt programming via a correspondence course from "Genooine Programg univercitee" and didn't care if a 1-minute process took 10 hours, because speed was not one of their requirements.
The boss then said "this is official".
Then those initial workers all got sacked or their lives made hell so they left. Nobody afterwards would particularly care about a process being stupid or inefficient because fixing it would cost money, not least because - as Calli Arcale pointed out above - it would require re-testing for quality, reliability etc etc.
Never mind that this cost would be more than made back a thousand times over by the long-term savings in time and efficiency. Because that would require thinking beyond next week, which rarely happens (because then the management would be Accountable).
And that is that.
Admin
I've experienced a very similar problem relating to writing to tape and dealt with it by raising a defect report for the official support highlighting that the constant stop-start of the tape drive represented a reliability risk for the drives and the tape content being written (no official way to verify the tapes). This got the standard WTF middle managers into a robot logic conflict of being unable to authorise the use of non-official software but also unable to officially agree the risks were acceptable. This led to a stall in being able to run the process at all leading to escalation and a request to me of whether I could make this problem go away and soon we had a new authorised version with the tape streaming nicely (and being checked afterwards).
Note that there was already a major WTF of the official process having no verification.
Admin
I don't get why anyone should babysit a machine for 11 hours. Let it run during the night, check first thing in the morning that everything went the way it was supposed to and you're done.
If an error occured, you can always start it again and THEN babysit it.
Admin
It was a military subcontractor. There were all sorts of rules about how to do the process. I literally HAD to babysit it. If I needed to go to the bathroom, I had to get someone else to babysit it during my absence!
Regarding the 'officialness' of the software: it was supplied by the military as a general-purpose bootstrap-from-tape loader, and the procedure specified that IT (and not substitutes) was to be used. The reason my boss let me use it was because I did the bit-by-bit verify of old/new discs. Nobody else was willing to take on the risk that the modified software that copied files from tape to disk would actually work.
Sigh.
Admin
The whole Cost Plus culture of military contracting encourages maximized inefficiency anyway. No matter how much is spent, it'll always come back plus 10%; the only risk is that your contract isn't renewed, which probably what caused the company to go bust in the end.
Admin
Hey, I remember what it was like to work for Lockheed, too!
Admin
Not every decision is technical. Some are legal. In fact, a lot of IT workers are employed for insurance reasons. Plenty of companies would try to run without security or compliance teams if it werent for insurance companies saying "no fucking way will we insure you on faith".
Hiring code analysts who can verify whether the new code is superior to the old code with no drawbacks would be hugely expensive. Simpler just run the original code while feeding back improvement suggestions.
Thats why some companies wont let their IT department do 3rd party addons to Microsoft products. Microsoft screws up? Sue Microsoft. Cowboy in IT thinks he is Linus Torvalds screws up? Company has to wear it.
Admin
In my experience, they're more than happy to fix it for you when you can contact their developers directly and tell them exactly what they should change to fix it.
With outsourcing, this has become increasingly difficult.
Admin
"Microsoft screws up? Sue Microsoft"
If you read the license agreement you have with any Microsoft product, you'll see that you have NO chance of getting anywhere with that. I don't know why management thinks they can "wring Microsoft's neck" when some M$ crapware causes problems: It's just not true.
Admin
The Sun streaming tape drive was a bit like this. If you wrote to it with tar's default block size, the drive would grind back and forth like a clapped-out washing machine and take forever. Telling tar to use a block size of a megabyte or two made it much smoother.