- 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
Ah, that old chestnut! Companies that hire developers but then won't let them develop.
Admin
For instance, this ultra-robust array building method, which skips simple assignation for laborious key/value reassignments:
Assignation - that word doesn't mean what you think it means. Perhaps 'assignment' was what you wanted?
Admin
".... And commenting the code might cause it to break.”
Hunh... now isn't that special.
Admin
Assignation - "the allocation or attribution of someone or something as belonging to something." I'd say that fits this case
Admin
Hmm. The real WTF is that the code used the mysqli_ interface rather than the old deprecated mysql_ interface. Too bad. If it used the old interface, the boss would have known he was lying when he said they couldn't afford to change it.
Moral of the story: if you're gonna crank out a bunch of misbegotten garbage code, be sure to use a deprecated interface or two, so your successors have an excuse to repair it.
Admin
"None of them have the time to maintain unit tests, and none of them want to"
None of the woodcutters has time to check his axes, and none of them wants to.
Admin
@Ron Fox: Have you already forgotten about http://thedailywtf.com/articles/the-inner-json-effect ? Comments are evil and DO break your "code" ;-)
Admin
I guess they are all too busy doing it again to find the time to do it right
Admin
"None of them have the time to maintain unit tests, and none of them want to. "
Ah yes I've worked with that type before. Can't refactor the old code because nobody is sure what would break since there are no unit tests. Can't write unit tests because nobody has the time (that's not completing your assigned tasks, you see), nobody wants to maintain it, in some cases nobody understands how to unit test, or worst of all the code is so sloppy that in order to write unit tests, you have to refactor the code, which you can't do because there are no unit tests to make sure nothing breaks. Repeat ad infinitum ad OutOfMemoryException.
Admin
Is it too late to get into another field? All this bad code and behavior... I should have become a plumber instead.
Admin
Ron might have been thinking of the more common meaning of assignation, approximately a synonym(1) for "tryst".
(1) English has almost no true synonyms, pairs of words that have exactly the same meaning, so "approximately a" is redundant in "approximately a synonym".
But then again, it might be appropriate in the context in which it is used in the article, because someone is getting screwed.
Admin
Why is ANY of this a WTF? Rule #1, if it works don't F%^& with it. We ALL KNOW THIS. We've all DONE this to ourselves at least once and hopefully never more. The junkier the code the MORE likely it is that a seemingly innocuous change will ripple its way into a disaster. So the leadership there was absolutely correct. Unless his task was specifically to enhance performance, leave EVERYTHING the F alone.
As for Unit Tests? Worthless. You're only testing things some predecessor (and how competent were THEY?) decided were worth testing. Parallel tests are the way to go. If you can't easily get the results into WinMerge, do an Astronomer's flicker test with Alt-Tab.
Admin
Developer (noob) is new to the company. Noob is told not to touch the legacy code because no one really understands it and they do not want to break it. Noob insists on going through the legacy code and trying to fix it. The RWTF is the noob.
Admin
There are two kinds of people who get written about on TDWTF: People who know better than everyone else and fuck up trying to prove it, and people who know better than everyone else but get shut down before they get a chance to prove it.
Admin
"Astronomer's flicker test" - nice terminology :-) Brings back so many memories of comparing configuration files on customer sites to find out what the hell they changed.
It's the one time I really appreciate an odd "feature" of windows notepad - if you open several windows at once they all open at exactly the same size and location on the screen instead of cascading like any sensible app would.
Admin
Or, try dealing with a distributed system where automated testing is nigh-impractical because the internal messaging layer's all tangled up with the static configuration data management layer to the point where you have to initialize an entire server task's codebase to test a single algorithm in it, and manual testing can't hope to catch all the corner cases. And oh, some of the most important bits of code in there violate separation of responsibilities (validating object states as you're trying to figure out what objects to validate? UGH!) to the point where they're utterly unmaintainable without heavy refactoring. (And oh -- there are bugs in said legacy code that need to be fixed, so you cannot simply leave it be!)
Admin
So wait, they're not allowed to edit the legacy codebase... but they have to fix bugs in the legacy codebase? Or is this company just writing a wrapper around the legacy codebase?
Alternate interpretation: the boss in this story is the developer in the story about The Inner JSON Effect taken to its logical conclusion: "I got fired for accidentally breaking a legacy program ONCE when I was still a junior developer, and that traumatized me to the point where I have to say no one is allowed to touch ANY legacy code lest this ever happen again."
Admin
My impression is that their development staff is engaged in the non-uncommon practice of turd polishing.
As for why the boss is refusing to allow changes to the legacy code, the most likely reason is that he wrote it, and he sees the deep voodoo that only he could possibly understand (even if he claims nobody understands it) is what keeps him in the boss's chair. If he didn't write it, then he's keeping it around, untouched, so that any further problems can be blamed on his predecessor. Either way, it's a very common issue of what's good for the organization isn't necessarily good for the person making decisions for the organization.
Admin
I didn't believe it until I saw it, but comments really can break applications.
Of course, it takes an absolutely heroic amount of stupidity to get there, but in one particular application I worked on someone was raw opening the source file to read variables which, you guessed it, were stored on specific lines. So you add a comment line, bam! Broken. Add a comment on the same line as a variable, bam! Broken.
I drank a lot on that contract.
Admin
Sorta like what happens when geniuses write macros inside Excel. Then someone adds a line to the worksheet, or decides to Hide or Unhide some rows, and kerflooey.
Admin
I doubt plumbing's any better than software development. My condo was built in 1975. The people who constructed used pretty much whatever was around on the jobsite without any thought as to quality or sense. Plus since we didn't have any sort of building codes back well, they built to a completely non existent spec.
If there was a DailyPlumbingWTF site our condo association would probably be on the front page.
Admin
I'm warning you. Try to understand, this is a high voltage legacy containment system. Simply editing a line could be like dropping a bomb in the city! My friend, don't be a jerk!
Admin
I would think that's a ridiculously dumb thing to do as well.
But I just remembered that we have that exact same scenario in our codebase. We do a lot of batch jobs, and in order to test changes, we need to be able to run the batch jobs in our testing regions. So we have the jobs saved on an sql table (WHY??) and when the test job is run, it takes the template from the sql table and replaces specific lines.
The worst part? The line replacements are hard coded. And the code base is in production. So in order to make a slight change to the naming of a testing region, we have to push a change all the way to production.
I want to punch everyone involved in this in the dick, but the guy who wrote it is a contractor who lives in different country.
Admin
"One day," Brian? No: Zero Day.
Admin
I am increasingly certain that in the future, I will require a prospective employer, to allow me a week to look at any and all source code I would be required to work on before I accept a job offer.
I will sign an NDA, but if they won't let me look at the code, then I don't want to work on it.
I've been so burnt by my current employer in that regard that I will try to never let this happen again.
I am a robot and you meatbags have had your chance.
Admin
The real WTF is a manager who thinks (or knows!) that commenting the code will break it and lets it remain that way.
Vote for Bender in 2016
Admin
"I work with eleven other developers. None of them have the time to maintain unit tests"
That's a sign on the wall right there.
Admin
True story, in college I had a horribly written assignment that wouldn't compile (more specifically it wouldn't assemble). I added a comment to a source file I thought might be causing the assembler issue. I then happened to rebuild it, even though no code had changed.
Tada! No assembler error! To this day I have no clue whatsoever why adding a comment to a C source file caused gcc to ouput different assembly code.
Admin
"Why is ANY of this a WTF? Rule #1, if it works don't F%^& with it. We ALL KNOW THIS. We've all DONE this to ourselves at least once and hopefully never more."
Done that, broke prod, got paged, fixed it again, and it was better. Breaking prod is not the end of the world.
Admin
Comments in javascript can be bad if the script would be minified (some old minifier are buggy on comment processing) are be passed through a few eval() calls (remember to double/triple/quadruple or even quintuple escape the special characters so it won't break.
For PHP pages, is there equivalent of the evil eval()?
Admin
But an assignment isn't as assignine!
(Also inb4: we had code that broke when commenting right here a few weeks back, with a flaky JSON parser.)
Admin
You can't really do an inb4 when @Falco20019 and @Pietro Gagliardi have both referred to that already.
Admin
They could have gone the "Strangler Pattern" approach and do some characteristics tests. This way the output is always the same, but it gives a chance to alter the inner workings of methods step by step.
Admin
I do embedded stuff, so not only is the basic concept of unit tests not trivial (your code doesn't even run on the same architecture as the compiler, how can you be sure it's really the same code you're testing, never mind how do you script the I/O devices), but sometimes you end up stuck on goofy versions of compilers.
In one situation, the co-worker in the next cube was having problems with a C function that started out with about 50 or 60 array assignments, like "foo[1]=something; foo[2]=something; foo[5]=something;" etc. The custom hacked third-party toolchain version of GCC 2.9.x (for the custom ARM variant CPU which nobody really knew how it was different, and the company had been acquired by $BIG_SEMI three years before and they re-spun the architecture, so totally legacy here) went nuts from that code. The register allocator started generating invalid assembler code because it kept wanting to use different registers until the point where the code started using R16 and R17.
But there was a happy ending. A year or so later that product went EOL (but not EOS), and I ended up maintaining it. One of the first things I did was replace that fucker with a table and a loop. A lot of other sloppy code got replaced with tables and loops, too. There were quite a few WTFs that I managed to remove from that code, and even though the monthly updates always added crap to it that would slow it down, by the time of EOS it was running at about the same speed as when I started with it, which was a major improvement.
Admin
The real WTF is the person who let that lovely Mini (https://en.wikipedia.org/wiki/Mini) rot beyond repair :(
Admin
ur mom aged like my vignedar's ass faget #rekt
Admin
If you don't know why "leaving it alone" is a WTF then you're guilty of WTF yourself.
"Rule #1, if it works don't F%^& with it. " -> How do you know it works? Just because the app isn't crashing doesn't mean it works - it could have try { ... } catch { // ignore } in there for all you know.
At the bare minimum documenting and unit testing the behaviour will ensure that (a) it does actually do what it's supposed to, (b) prevent problems with it in future when someone else changes it to fix their problem.
Admin
For maximum amusement with over-enthusiastic catching, try Visual C++ v6, in which catching "..." would catch everything.
By that, I don't mean "all C++ exceptions", which is its defined behaviour. On VC++6, it also catches all SEH exceptions. Granted, most of them are UB if they happen (dereferencing a NULL or wild pointer is UB, folks, no telling what will happen), but I had to deal with a library that would not crash. Not at all. Because at all entry points (and in assorted places internally), it had a do-nothing catch(...). It was also littered with bizarre code, like functions that overtly declared variables to have the storage class
auto. Not its more funky modern use, where it means "determine the type automatically", but the old C-style use, meaning "in the per-call activation record", more commonly (and erroneously) termed "on the stack".Admin
My guess is the object file was outdated, maybe due to a missing dependency in the makefile. Updating the source caused it to be rebuilt, regardless of any (or none) actual changes to it.
Admin
The point is, as a plumber it is a given that you'll be dealing with somebody else's sh~t all day.
Admin
this whiner keeps complaining about it being "inefficient" and it never mentions anything about an actual performance issue. typical code-monkey bullshit. this idiot can't see the forest for the trees and would rather unravel the whole damn system than do his f-ing job.
Admin
"As for Unit Tests? Worthless. You're only testing things some predecessor (and how competent were THEY?) decided were worth testing. Parallel tests are the way to go. If you can't easily get the results into WinMerge, do an Astronomer's flicker test with Alt-Tab."
With any testing, you're only testing what the person in charge of the testing decides is worth testing. If you do unit testing, it's the test developer. If you do manual testing with test scripts, it's the author of the test scripts. If you do ad hoc testing it's whatever the tester feels like doing. Unit tests (and integration tests) have clear advantages over the others (which is not to say the others don't have their places).
Admin
Relevant Hanselminutes (#539) about a company that specializes in managing Legacy Code: http://hanselminutes.com/539/learning-to-love-legacy-code-with-andrea-goulet-from-corgibytes
Admin
Haha! "Astronomer's Flicker Test"... I didn't realize that there was a name for this. I have used this technique on several occasions.
Admin
Wait, didn't we have a story on here where a comment did in fact break the program? AFAIK it was because the compiler couldn't quite cope with the comments (or the characters used to comment a line) and as a result it broke the whole program.
Admin
Cool story brah!
If you're writing PHP to be transpiled to an embedded system, your Darwin award is in the mail. Given that the story is in PHP, your "but on embedded systems" comment can fuck off.
Admin
I've encountered this pattern several times. The second time, I let it be for a while, until one day, I received a bug to work, found it was in the legacy code, but the grep I used to *find* it also revealed that the code was using an interface that hadn't *existed* back when the legacy code was supposedly written. So I made a source control directory under my home, copied all the files there, and checked it in. Kludged around the bug as per normal with legacy code issues, and went back to work. Next week, compared the 'legacy' code to my copy, checked who was on, checked the changes into my version control as the only person who'd been on at that time, using the file changed time as the update time instead of modify time, because they thought they were clever. Repeat a few times, then reported the guy (who happened to be the person saying legacy code was untouchable) to his boss, given that evidence. Note that I didn't just wait until I had a critical amount of evidence, but also until the latest "newly discovered problem in the old code" was sufficiently critical and sufficiently braindead. My immediate supervisor hated me and tried to get me fired in his last week, but he didn't last long enough.
My last time of encountering the untouchable legacy code problem, I happened to outlast everyone who was saying OMG cannot touch, and then I touched, and built my career at that company over the amount of improvement we got from it. Because it certainly was not an "If it's not broke" situation, nor a "not really apparently inefficient." The users didn't care exactly how efficient the new solution was, but they certainly cared that it was at least a hundred times faster. That said, I hadn't spent hundreds of optimization cycles to get the best solution that I could; I just wrote something that wasn't godawful, and it was more than enough better.
Admin
I think my favorite part of this scenario is the 'nobody' bit. When I've been in one of these situations where 'nobody' understands the legacy code, 'nobody' wants to do unit tests, 'nobody' this and that - there was usually somebody besides me who was interested in what 'nobody' wanted to do and could understand what 'nobody' understood. It was just the guy in charge who wasn't interested and didn't want to be bothered by it. Or wanted everyone to think he wasn't interested so that they wouldn't fix his code with techniques he didn't understand and couldn't replace because his stuff would be buggier.
Admin
Fortunately PHP isn't compiled. It's already broken anyway, so nothing to worry about on that front. Reading this reminds me far too strongly of my first dev job in the mid 00's. Cringeworthy.
Admin
At least in JavaScript, if I had an object
o, and deleted all the keys on it, and then restored one key that I'd saved earlier, then anyone else with a reference to that object would observe the changes that I'd made. Whereas if I'd just assigned a new value too, nobody else would be any the wiser.