My first job experience was similarly full of WTFs, even at some point I looked at my code and said WOW, I WROTE THAT?

Unfortunately when I said that this code is "Horrible and Stupid" it was because an Action Form was passed directly into a database object and converted into a sql statement. Needless to say it was impossible to write a SINGLE test case. 90% of QA could have easily been converted into test cases, had the code been written correctly.

But hey it was a learning experience and I am glad to have seen it. You don't learn by working with the best, you learn by working with the worst, then working with the best to see the contrast :)

MK:

There's got to be a bit of a question over why it wasn't in source control, I mean ready or not the latest version should have been there so it gets the same protection as the rest of the source code. It doesn't need to be in the production branch.

You assume that they use branches in their source control. Out of 3 companies I have worked at only one has uses branches for version control.

I actually feel a bit sick, I've had anxiety problems in the past (what programmer havn't ^^) and I recognize the panic Jared must've felt. That's the first time a WTF is more disturbing than funny to me, even though I agree with Ken that Microsoft really is 'horrible and stupid'.

Yuck!

It still could have been placed in a "not ready for prime time" directory just for safe-keeping. Or check in a version with an immediate exit stuck in if you're worried about someone insisting on running it before it's ready. Especially if he were leaving, I'd think there'd be a good chance IT would just wipe his machine to prepare it for the next user.

I've seen the types that immediately start bad-mouthing everything, and the accepting types that acquiesce to this loud one.

A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win. An advanced technique is if they insist that they're calm, say it again and again until they do get agitated.

you: i think java's the bomb

other: well, maybe if you're doing middleware development, but in cases of Windows fat clients, you're probably better off going with .NET

you: now just calm down.

you instantly win! try it out.

suzilou

suzilou:

A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win. An advanced technique is if they insist that they're calm, say it again and again until they do get agitated.

you instantly win! try it out.

suzilou

Ok, I can see you are quite emotional about this technique, but just calm down a bit!

MK:

There's got to be a bit of a question over why it wasn't in source control, I mean ready or not the latest version should have been there so it gets the same protection as the rest of the source code. It doesn't need to be in the production branch.

I'd agree. I check stuff into source control as soon as I create the files.

This story was horrible and stupid.

Jared snapped out of his panic with the wonderful realization that these weren't his problems as a CollaboSmart employee.

i love it when that happens. like when you wake up on a saturday thinking it's a weekday and have a 30 second panic before realising you can spend an extra couple of hours in bed. ahhhh... sucks when it happens the other way around though :)

those that are saying he should have checked his script in: no i disagree. if something is not ready then it shouldn't go into source control. my basic assumption is that if something is in then as far as the developer is concerned, it works. i learned this the hard way - someone checked something in, someone else cavalierly released it to UAT, and i was the fire fighter lumped with the messy rollback

What's the point of having source control if you aren't going to use it? Sheesh.

Ok nice story. But,,,,, How many programmer only have one copy of a peice of code they have worked on for a month.....?

Uh,,,,,, None.

So sorry but I'm calling pooo on this whole story.

A Nonny Mouse:

Jared snapped out of his panic with the wonderful realization that these weren't his problems as a CollaboSmart employee.

i love it when that happens. like when you wake up on a saturday thinking it's a weekday and have a 30 second panic before realising you can spend an extra couple of hours in bed. ahhhh... sucks when it happens the other way around though :)

those that are saying he should have checked his script in: no i disagree. if something is not ready then it shouldn't go into source control. my basic assumption is that if something is in then as far as the developer is concerned, it works. i learned this the hard way - someone checked something in, someone else cavalierly released it to UAT, and i was the fire fighter lumped with the messy rollback

Uhh, what...?

Seriously, source control isn't just a big directory which is copied to production now and then. If you don't have any way to differentiate source code that's in development from source code that's ready for testing from source code you can safely deploy, that's not the fault of source control -- that's people not using it properly.

A Nonny Mouse:

Jared snapped out of his panic with the wonderful realization that these weren't his problems as a CollaboSmart employee.

i love it when that happens. like when you wake up on a saturday thinking it's a weekday and have a 30 second panic before realising you can spend an extra couple of hours in bed. ahhhh... sucks when it happens the other way around though :)

those that are saying he should have checked his script in: no i disagree. if something is not ready then it shouldn't go into source control. my basic assumption is that if something is in then as far as the developer is concerned, it works. i learned this the hard way - someone checked something in, someone else cavalierly released it to UAT, and i was the fire fighter lumped with the messy rollback

Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

Releasing to UAT straight from Source control without any QA is your problem. Where was the project manager in this and who said it was ready?

And with that, Jared saw nearly a month's worth of work disappear. He hadn't put it into source control yet because it wasn't quite ready, and he didn't want someone to confuse it with a working version and run it.

It's still early in the day, but I doubt I'll see anything more horrible than this today. I can understand requiring that versions compile, but if you only put working versions of code into source control, you

(1) Are stupid
(2) Will lose work
(3) Could get the same level of protection by simply backing up archives of your releases.

TCS:

Ok nice story. But,,,,, How many programmer only have one copy of a peice of code they have worked on for a month.....?

Uh,,,,,, None.

So sorry but I'm calling pooo on this whole story.

You're obviously new here. :)

And welcome...

A Nonny Mouse:

like when you wake up on a saturday thinking it's a weekday and have a 30 second panic before realising you can spend an extra couple of hours in bed. ahhhh... sucks when it happens the other way around though :)

you mean when you wake up and have a 2 hour panic before you realising you can spend an extra 30 seconds in bed?

KattMan:

Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

TCS:

Ok nice story. But,,,,, How many programmer only have one copy of a peice of code they have worked on for a month.....?

Uh,,,,,, None.

So sorry but I'm calling pooo on this whole story.

I have another issue with this story - I expected to find out the new guy was the nephew of the CEO or something ... how else would he be able to walk in and immediately put four projects on hold?

Anyway, as for your question - more programmers than you think. I recently took over a web application from someone who left, during the QA cycle, to find that QA was getting 404 errors with one whole section. The files aren't in the install rpm, or source control, or in the backed up copy of his home directory. Either he just didn't bother doing the work (possible but or unlikely), or he did his dev work in a nonstandard place (we are supposed to have everything we do in our networked home directories) and forgot to check it all in before he left.

So I'm in the middle of trying to find out exactly what these files were supposed to do and recreating his work.

dpm:

KattMan:

Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

Um actually, yes we do; sadly. But even beyond that, if you are working on a library that is used by other developers, your checked in code should compile so that the other team members do not have to worry about your errors while working on prototypes of their own.
This is where stub functions are really helpful. New functionality is added, you create the stub but not ready to actually write the functional code. Check it in with just the stubs so the other developers can use it and make calls to that function. The only way they can do that is if your code compiles, it doesn't have to actually do anything yet.

This article reads like a bad S.A.T problem. Jared and Stephen meet for lunch to talk about code. Meanwhile, Chris and Eva are travailing on a train east bound from Odenville. At what time will Stephen’s code arrive at Ken’s train station in North Havenbrook? I’m so sick of names!!!

Anon:

This story was horrible and stupid.

This comment is horrible and stupid.

WTF would you sit down to lunch and tell the person that has left your organisation about all this badness ?

KattMan:

Releasing to UAT straight from Source control without any QA is your problem. Where was the project manager in this and who said it was ready?

hahahahahahahahahaha.... *wipes tears of laughter from eyes*

nobody said i wasn't working with cowboys :)

but yes, your point about stuff compiling is what i meant by the developer thinking "it works". as long as it doesn't screw up everyone else. not checking things in is an extra precaution. for stuff like scripts i would keep local copies and copies on a network drive while i was still working on it. or at the very least mark it as "not ready" when adding to source control.

KattMan:

dpm:

KattMan:

Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

Um actually, yes we do; sadly. But even beyond that, if you are working on a library that is used by other developers, your checked in code should compile so that the other team members do not have to worry about your errors while working on prototypes of their own.
This is where stub functions are really helpful. New functionality is added, you create the stub but not ready to actually write the functional code. Check it in with just the stubs so the other developers can use it and make calls to that function. The only way they can do that is if your code compiles, it doesn't have to actually do anything yet.

Yeah, I think this is one of those things that will vary by language. With Java, most IDEs will automatically detect and add any new files to the build path. You can manually exclude files but it's difficult to push the list of excluded files to other developers.

From the article it sounds like it was just an administrative script, though, so it's not even like it needed to be compiled. The Real WTF here is that this guy didn't double check all of his files and check them in on his last day of work. Sucks when the guy leaves but didn't check in his work or forgets to release the lock on a file (stupid VSS...)

I once wrote the key communications subsystem for a $10Mill defense company project that touched every raw material that came in the door to build their military product. Before I left the company I carefully documented the source, saved it external to my PC (this was the early 80s) as a backup so it couldn't be lost.

A few months later a group of my replacements came to me and wondered if I had saved a copy myself. Apparently the PC was reformatted and all my documention and backup disks were lost. Thus they couldn't make any changes at all to the system except in binary.

I think the company sold the whole division to another defense company soon thereafter...

bdew:

Anon:

This story was horrible and stupid.

This comment is horrible and stupid.

This thread is horrible and stupid.

One might be expected to at least greet and chat a bit to the bloke, the reason is clear if you read the story:

"Anyway, Jared, remember that script that you were working on right before you left?"
...
"Ken decided that he didn't need it and deleted it. You didn't happen to hang on to a backup copy, did you?"

He was looking to get a backup copy of the deleted file from Jared, hence the lead in.

Helix:

WTF would you sit down to lunch and tell the person that has left your organisation about all this badness ?

It might be that thing called friendship.

dpm:

Seriously, why would a build attempt to compile a file just because it was added to source code control?

Because your team is using Cruise Control.

I've walked into a job and complained about everything being horrible and stupid. Of course, they weren't using source control, didn't have an automated build system, had code that was blatantly incorrect, and had hard coded references to databases that needed changed for deployment to each environment.

To be fair, the last two were the reason I got the job - the previous guy was clueless.

TDC:

Helix:

WTF would you sit down to lunch and tell the person that has left your organisation about all this badness ?

It might be that thing called friendship.

Maybe; or it might be that thing called networking. Your former coworker got a better position, and you'd like to get one, too; maybe where he's working now.

What source code tool doesn't provide for separate test and build environments? Checking in a source file with a new rev shouldn't automatically make it part of the build - thats just ridiculous.

dphunct:

bdew:

Anon:

This story was horrible and stupid.

This comment is horrible and stupid.

This thread is horrible and stupid.

All of you just calm down.

crxs:

suzilou:

A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win. An advanced technique is if they insist that they're calm, say it again and again until they do get agitated.

you instantly win! try it out.

suzilou

Ok, I can see you are quite emotional about this technique, but just calm down a bit!

Or as a friend uses:

"Well bless your heart! What a charming idea."

It helps if you are over 50 and female, but there is nothing anyone can say back to that one, lol. I guess there are advantages to being a middle aged woman.

suzilou:

A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win.

Do not try this technique with your spouse, especially your wife. It just pisses them off more. And you will definitely NOT win.

my name is missing:

I once wrote the key communications subsystem for a $10Mill defense company project that touched every raw material that came in the door to build their military product. Before I left the company I carefully documented the source, saved it external to my PC (this was the early 80s) as a backup so it couldn't be lost.

A few months later a group of my replacements came to me and wondered if I had saved a copy myself. Apparently the PC was reformatted and all my documention and backup disks were lost. Thus they couldn't make any changes at all to the system except in binary.

I think the company sold the whole division to another defense company soon thereafter...

And if you'd said "Yes, I have it right here", they'd have promptly thrown you in jail for stealing defense department secrets.

calming down:

Or as a friend uses:

"Well bless your heart! What a charming idea."

It helps if you are over 50 and female, but there is nothing anyone can say back to that one, lol. I guess there are advantages to being a middle aged woman.

Definitely creepy if you're not female. And it would be helpful if the recipient is not aware that the phrase "bless your heart" means "you're an idiot"... :)

It's impressive that guys like that are not fired by the managers. The problem is always on the top, all the time, for all the companies, in every place of this world.
I've worked with guys like that. I hate religious guys who think that their tool is better than all the other tools, that Microsoft is the evil and Linux is the paradise.
I work with a guy that likes to replace all small pieces of code in JSP files (not logic, just presentation) for the standard tag library, and I would not have A problem with that, if he didn't introduce more than one bug for conversion made.
It sucks.

"He hadn't put it into source control yet because it wasn't quite ready"

Now that's a WTF. "Wasn't quite ready"? For what? Keeping track of the history of the code? It might not be quite ready for *release*, but anything over a couple hours should be in a repository. A *month* just makes it the developer's fault. There's no one to blame here but himself.

Helix:

WTF would you sit down to lunch and tell the person that has left your organisation about all this badness ?

Yeah, of course. I bitch to my former coworkers about stuff going on at work all the time, and I hear from other former coworkers about problems going on where I used to work. It's not like they don't already know how screwed up the company is.

Ravi:

I've worked with guys like that. I hate religious guys who think that their tool is better than all the other tools, that Microsoft is the evil and Linux is the paradise.

Microsoft is evil, and Linux is the paradise.

That's still not a reason to randomly introduce the risks of a change in platforms. If I were his manager, I'd sit him down for a nice old fashioned firing.

Anon:

This story was horrible and stupid.

...now just calm down...

dphunct:

bdew:

Anon:

This story was horrible and stupid.

This comment is horrible and stupid.

This thread is horrible and stupid.

This forum is horrible and stupid.

*yawn*

Why would you even care if you don't work there anymore? Grow a pair buddy.

Phleabo:

Ravi:

I've worked with guys like that. I hate religious guys who think that their tool is better than all the other tools, that Microsoft is the evil and Linux is the paradise.

Microsoft is evil, and Linux is the paradise.

That's still not a reason to randomly introduce the risks of a change in platforms. If I were his manager, I'd sit him down for a nice old fashioned firing.

Come on Ravi say it....say it.....

dphunct:

bdew:

Anon:

This story was horrible and stupid.

This comment is horrible and stupid.

This thread is horrible and stupid.

The Internet is horrible and stupid.