Slashdot Mirror
Dirty Coding Tricks To Make a Deadline
Gamasutra is running an article with a collection of anecdotes from game developers who had to employ some quick and dirty fixes to get their products to ship on time. Here's a brief excerpt:
"Back at [company X] — I think it was near the end of [the project] — we had an object in one of the levels that needed to be hidden. We didn't want to re-export the level and we did not use checksum names. So right smack in the middle of the engine code we had something like the following. The game shipped with this in: if( level == 10 && object == 56 ) {HideObject();} Maybe a year later, an artist using our engine came to us very frustrated about why an object in their level was not showing up after exporting to what resolved to level 10. I wonder why?"
Have you ever needed to insert terrible code to make something work at the last minute?
Right before I left from Microsoft: int security = *NULL; // eat it!
Most people don't get why the integral of "e to the x" is so funny. Most math majors don't have a sense of humor.
GOTO :-) (or is that two..?)
[Slashdot Comments We Liked]
If you have short deadlines, you end up with issues similar to the bugs Ubuntu needs to smooth out every release. If you go with "It'll be finished when it is finished", Your stable releases can become ridiculously out of date between versions. Debian did a good thing by abandoning the open-ended release cycle in favor of the extremely long but predictable two-year deadlines.
Once I had an assignment due and at the last minute before being evaluated, realized I had made a huge mistake, even though the code looked OK...
Too much time playing games in class and I was about to fail the course unit if I didn't pass that one test (right at the end of a semester)
So I ran the program, adjusted the output in a word processor, saved it as a file and threw some code hidden in the comments that read the file, outputted it and exited.
Three minutes later my code was evaluated... I was the only one who passed.
Fortunately, no one investigated too carefully at the time why I was the only one who passed, because after trying to fix the code later in my own time, I realized the source data we were all supplied was corrupted.
Inevitably, Later the same lecturer came to the same conclusion when his program didn't work either and cornered me to ask why mine worked (of course he was suspicious). Thinking quickly, I told him my source data was corrupted and that I fixed that first so my program would work. I don't know if he believed me, but he accepted the story.
Fortunately, I got away with it and I got to keep the pass.
The editor might have approved this submission just to meet some kind of deadline or a minimum requirement.
Have you ever needed to insert terrible code to make something work at the last minute?
Wouldn't "have you ever shipped a product without needing to insert terrible code to make something work at the last minute?" be a more sensible question?
This is one of those stories where the story isn't the point, it's the comments that are worth reading, so it's only a problem if we have the same comments :-P
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
When my deadline comes up and I haven't produced I wait for my boss to ask me for the code then I sucker punch him and run away. The trick is to hold down short term contracts and give false references and hire someone to back them up (another dirty trick). That also makes it easier to dodge the cops when your boss presses charges. It's getting harder though with all this talk of test driven development and short incremental releases. Then the trick becomes to write the most meaningless trivial unimportant tests first - but crucially tests that you can make pass quickly so you don't have to do any real work.
(For anyone insane enough not to realise it, this is a joke. Don't try this at home...or at work).
A 3d model export would break regularly screwing up the texture map orientation on certain polygons. The godawful export couldn't be fixed on the deadline, and risk management said best not to touch it cuz EVERYTHING might bust, let alone all the coders being nailed to the wall by the ship date. So I fixed the model files in an ascii editor. All the art builds that had tweaks needed this "touch" Since it was a hockey game, you can imagine how many goalie pads that was. Oh yeah, you couldn't see if the fixes were correct except in the game engine after more pipeline.
Technically not a code fix, but still a valid solution.
I once worked at a Fortune 25 company in Chicago. They had this ENORMOUS mainframe program written in COBOL that ran their order inventory system which accounted for 20% of the companies revenue. All the guys who wrote this grunting pig of a system had either retired or had passed away. In the middle of the code was the following;
*
* We don't know what this does.
* Please leave it alone !
*
SET INSIDE-INDEX TO 1.
*
* We don't know what this does.
* Please leave it alone !
*
If this statement was commented out or removed the system stopped working. No one could find the problem. People had spent years looking for it but the code was such a mess and the documentation was so useless that they just left it alone and made a note that when the order inventory was re-done to make sure they left this "feature" out. I have been told that many old system have similar problems.
Another day closer to redwood heaven
In the real world there are deadlines, and it's entirely the developer's responsibility to be able to meet those deadlines without using such "dirty coding tricks". Good developers should have tested their code so as to not have serious problems to fix at the last minute, and designed it so as to be able to extend it easily.
Yes, because deadlines are always reasonable and never pushed up. And change orders are a myth.
#DeleteChrome
Way back we had a project where we had to simulate entire train traffic entering Helsinki train terminal. Someone else had made the simulator and it ran pretty neatly, but unfortunately crashed mysteriously after about four - six hours of simulation time. Our customers were coming the on monday and I spent my sunday trying to figure out how this simulation worked and what crashed it. Finally I caught the problem, which was as simple as some null pointer to a train schedule or something similar which needed to be referenced. I couldn't figure out why it was null in time, so I just added test for null pointer, which skipped said code. Program ran fine and we got our money. Never figured out what was wrong with it. Luckily it was only a simulation.
John Titor sent it just before disappearing.
Where'd he get to anyway?
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
This was a pretty important assignment back when I was studying computer science. It added to the final mark mark for that particular class. The task was to write a reasonably complex application in Prolog or some functional programming language, I can't remember which it was. I think the goal was to pair males and females based on their preferences, and find the optimal solution. Of course, I screwed up royally, and nothing worked five minutes before I had to demonstrate my solution.
So in the final five minutes, I changed my code so it would avoid the parts which put it into an infinite loop, and instead simply output a random result. My goal was to tell the prof that it had worked a few minutes earlier, and that I didn't know what had gone wrong, and could I please have another week?
So I demonstrated my app, it gave its random output, and I was about to start with my "damn, it used to work properly" spiel when he said (and this is actually true, even though it sounds unbelievable):
"That's great! The result is correct, and your app is also quite a bit quicker than my own implementation of the problem. Congratulations, I think you're the only one so far who managed to get the correct result so far."
I was so taken aback that I probably just stared at him for a few seconds. Then, I stupidly said "So... You want to see my code?" but he was like "No, the result is correct, and your implementation is very fast, so I don't need to see the code. Good job. Send in the next guy."
And so I did.
He's fighting in the civil war we're apparently not having, guess he fixed our timeline.
The Goal: A long simple life filled with many complex toys.
Example? Right here:
#include <stdio.h>
void *f(void)
{
a:
printf("Here!\n");
return &&a;
}
int main(int ac, char **av)
{
goto *f();
printf("There\n");
return 0;
}
Slashdot sorely needs "douchebag" moderation.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
After years of programming, I guess everyone had to cut some corners sometimes. It's also not (always) a problem of goofing off, a module you depend on not shipping in time but you being required to keep your deadline can already force you into doing just that: Delivering a hack that 'kinda-sorta' works, or at least the customer won't notice 'til we can ship the patch.
Yes, that happens often. It's dubbed "Bananaware". Delivered green and ripens with the customer.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
> it's the comments that are worth reading
More specifically the comments in the article. I loved this one:
"Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander.""
That's awesome.
Basically ALL the software you use works like this.
Welcome to the real world, no need to feel bad.
Some of the worst I have seen:
In critical C code:
if (some condition)
i *= 0;
else
i *= 1;
And I was the actual variable name.
Even worse, on a different project, an Easter egg that told the user their hard drive was about to be erased, and another that popped up about 30 dialog boxes full of banter between Spock and Kirk. Worst of all this code written in VB and was licensed for megabux then we got hold of it for orders of magnitude more megabux (Most of the original coders were hired fresh out of highschool). It ended up being rewritten (thankfully NOT by me) but we had to get the source to work out how it worked in the first place.
I wish I was making this up.
These posts express my own personal views, not those of my employer
That's completely understandable in this case of programming in Prolog.
Prolog is a declarative language.
You declare the rules, and the system figures out a result that matches those rules.
The problem is that this basically doesn't work. So a Prolog programmer has to write the "declarative" rules in a procedural order so that the run-time system doesn't have to try every possible combination to find (or fail to find) a matching result.
The proper ordering of declarations can be quite subtle. With a modestly complex program you can make a seemingly unimportant change in the order of the declarations and have the runtime go from a second to a week.
In this case the professor didn't (couldn't) know how long a Prolog program to solve this problem should take. He just assumed that you had found a more efficient ordering for the declarations. He might even have thought it was luck rather than deep insight that your program was faster than his. But you have to a decent understanding of the limits of Prolog to get a complex program to complete in a reasonable time, so you had to be good before you could get that lucky.
If you couldn't already tell, I have a low opinion of Prolog and declarative languages. They are "parlor tricks". Much like computer 'Life' and neural networks, simple programs can produce unexpected seemingly-sophisticated results. But they don't get better from those initial results. To compute the answers or results you want in a reasonable time, you end up with at least the complexity of writing things in the traditional explicitly procedural method.
The promoters of declarative language typically don't mention that you end up writing rules in an explicitly procedural order if you want the program to work. If you press them on the issue, they then say "well, OK, it's not actually any easier to write, but it's easier to verify that you've correctly specified the desired result." But if you have to carefully shuffle declarations around, and even then some results unpredictably take centuries to compute, pretty much no one cares.
So it was 1999 and I was working for a mom and pop software shop, we had been acquired by a dot com. All our money and toilet paper stock options were held until we delivered the re-branded product with source. Part of the "rules" said we had to have only C/C++ and VB6 source, NO OTHER LANGUAGE.
....(you get the idea)
. We finished converting a few rogue scripting modules and things like that, which creep in over time. But we COULD NOT find the source code to one of our VB6 DLLs (an old one that had not been changed since it was first compiled in VB6). We searched and searched and eventually the fastest coder(not me) started rewriting it. We were 1 day from delivery date and there was no way he could finish it, so I ran it through a disassembler.
the C++ code we delivered looked like this:
int functionName(int parm) {
_asm {
push esi
mov esi, dword ptr ds:[esp+8]
mov dword ptr ds:[edi], esi
retn
}
It was unreadable, but it compiled and worked and we got our money. I still wonder what they ever did with that... since the software is still in use...
We had an easter egg in our code that was in a routine scheduled to be executed only at 0-dark-30 when our users were long gone. But someone later called the routine as part of the loading process, and the users ended up seeing it anyway as they signed on at start of day. It made people smile, so we left it in.
A few years later, we were telling a client that we couldn't add their new feature X because we don't have the memory. At that point the director said to get rid of the easter egg and then it'd fit. (A few hundred bytes was not going to make a difference, but our director didn't care, it was a perception thing.) What we got instead was a hundred bug reports that the easter egg wasn't displaying, and that they "needed" to see it so they'd know when start of day was complete.
John
This is the code for the Apollo 11 lunar lander flight computer.
http://code.google.com/p/virtualagc/source/browse/trunk/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.s?r=258
and yes some of my code is in there along with the equivalent of a few "goto's
Lots of bright people worked on this and in some circumstances a "goto" is required.
*--- Sometimes a majority only means that all the fools are on the same side. ---*
I believe another name for that little snippet is "buffer overflow vulnerability".
I am officially gone from
Back in college, we were at a programming competition and I was the on-the-keyboard coder for one of the problems. We had 10 minutes for the problem and I coded it quickly, having decided on the best algorithm before sitting down. Part of the solution was a sorting routine on a list. We were using Visual C++ although we were all not C++ experts at the time, and so rather than mess with the STL and the possibility of having to read documentation, I did it all from scratch. I knew that sort was already in use by the standard library, so I called my routine mysort.
Apparently, however, Visual C++ includes a mysort in its standard library. So, with the clock ticking down and the solution's only impediment to our victory being an identifier conflict, I renamed the routine the way that any one of us would have: myfuckingsort. We won the competition.
In this particular competition, the judges were not supposed to read our code - they just run the output of your code on the input and check for correct output - so I felt safe when I typed what I did. However, one of them came up to us afterwards and told us that they do in fact usually read the code of the winning team to see if we did anything unique in our solution. Yep. Sure did. And my classmates and professors never did let me live down what was affectionately nicknamed the fucksort algorithm.
Wait, you were serious? Does your hair come to points on the side of your head, by any chance?
If I could cope with unreasonable deadlines without some sort of nasty compromise, I wouldn't be developing software. I'd be turning water into wine, holding back the tide, etc. "Good software developer" doesn't mean "miracle worker". If the time isn't there before the deadline to solve the problem correctly, either the deadline will be missed or the problem will be unsolved or poorly solved. That's close to a tautology; it's implicit in the term "unreasonable".
Well, in part, but another important lesson in science labs is learning to report the truth, even if is disappointing and not what you want. This is an important lesson and unfortunately even some well known scientists don't learn it,