• BlueEagle (unregistered)

    Soo.. the wtf is that they broke the fix or that they couldn't read?

  • Anonymous (unregistered)

    So the real WTF ist that "Development" doesn't, or doesn't want to, understand plain english comments?

  • (cs)

    A WTF where the guy being replaced WASN'T the problem!?! Awesome. It's nice to get a change of pace around here.

  • (cs)

    That's funny. Arrogant, self-righteous developers who think that their code is 100% perfect and bug free, when in fact it's not. And to top it off, they forced someone who, from what we're shown, knew what he was doing to leave the company due to their ignorance. Lovely. I've met my fair share of these kinds of buffoons. And for some reason they're always the ones who stick around with the company.

  • John Doe (unregistered) in reply to bstorer
    bstorer:
    A WTF where the guy being replaced WASN'T the problem!?! Awesome. It's nice to get a change of pace around here.
    Yup, but after a second reading it turned out there was a giveaway: "Being that they were an enterprise software provider"

    I guess they didn't understand Josh's fixes, because it didn't contain XML.

  • dummy (unregistered)

    I like the way we feel, getting closer and closer to Josh's brillant WTF.. just to discover HE seemed to be the only sane guy around.

  • (cs)

    This is why descriptive names sometimes don't pay - idiots get defensive when you call their stuff "broken". better to just quietly fix it in a piece of code with an obscure name. I'll bet that's what Brian did, too - put the same piece of code back in under a name like "dbcleanup" with all the comments removed and replaced with a single "# fixes for 4.02.1 errors per ticket #NNNNN"

  • Cloak (unregistered)

    Well, this is again one of these "Consultants/Independants are only highly paid and we the enterprise(y) staff who know our work..." stories.

    Not all consultants are bad. But what cann you do against stupidity and ignorance from the tech staff side. In this case they had more power. Maybe the project's sponsor should have done something about it. In the end he still managed to get the budget for another consultant.

    I am actually happy to see that not all of us Paula Brillants. And BTW "Someone you know" "Brilliant" is German. :)

  • (cs)
    As one of the developers put it, “Brian just kept mucking around with our Database and we simply removed his CVS access.”

    Should that say: "Josh just kept mucking around...?"

  • Joel (unregistered)

    WTF with a twist. I really enjoyed this one.

  • evilghost (unregistered)

    I can only imagine the look on Brian's face when he discovered that Josh wasn't a slaptard at all and that the incompetent development team drove him away! I can almost envision the look of despair on Brian's face as a result of the battle he just inherited; his entire world did a 180.

  • Josh (unregistered)

    Look on the bright side; about the most work Brian probably had to do his first week on the job was a bunch of uncommenting!

    CAPTCHA: onomatopoeia ... are we checking to see if I'm not a robot... or is it just the bad typists we're trying to exclude? Actually... what a great idea :P

  • Daniel Migowski (unregistered)

    Don't you all realize that Josh just modified live data in databases just to get his poorly programmed update running? He add's "receivedDate"s for stuff not yet received just to do his stupid update, and just because he is not able to code correct update scripts.

  • Brian (unregistered)

    I'm a different 'Brian' than the one in the story... but I feel like my current project could have taken the place. I've been asked to help people do C++, but they insist on doing C+ - and doing it badly. Worse, they really only want me to tell them they're doing fine. And I'm not a consultant, I'm an employee hired as a programmer.

  • (cs) in reply to evilghost
    evilghost:
    I can only imagine the look on Brian's face when he discovered that Josh wasn't a slaptard at all and that the incompetent development team drove him away! I can almost envision the look of despair on Brian's face as a result of the battle he just inherited; his entire world did a 180.
    I agree, very cool, I wholly enjoyed myself. Josh did what he had to do (assuming he actually confronted the Development staff first about this stuff). The only thing I didn't like about what he did was:
    print "Call Josh at 440-555-0221 and tell him what the following output says...\n";
    He probably would have had an easier time showing them the errors of their ways if he had written the output to a log file (say for a given day) and then showed them the results of the log. Even so, this approach does allow for the end users to know who to contact, so it can't be all that bad.
  • anonymous (unregistered) in reply to Daniel Migowski
    Daniel Migowski:
    Don't you all realize that Josh just modified live data in databases just to get his poorly programmed update running? He add's "receivedDate"s for stuff not yet received just to do his stupid update, and just because he is not able to code correct update scripts.

    You might actually want to reread the story...

    Josh was not a developer, he was merely there to support the installation and upgrade of the software by technicians.

    Besides, his fixes are perfectly reasonable from the looks of it. "valid date" and "no date" are two completely different things. An invalid date could be 25/25/1000 which is obviously impossible.

  • (cs)

    No testers, no bugs. The smart path to 100% bug-free software.

    If there is a problem then it must be a user error. Our software does not have any bugs, it's enterprise software after all!

  • mh (unregistered)

    The real WTF here belongs to whoever let the developers set up and manage the database...

  • Phil B (unregistered)

    There should be a shrine to the memory of Josh

  • Edward Royce (unregistered)

    Hmmmm.

    1. Ask around and find out the cost ($) per minute of tech support to correct problems in installation.

    2. Log all such requests by the minute.

    3. Present report to manager showing definitely how much the dev team's incompetence is costing company.

    4. If nothing's changed, change job.

  • Eeve (unregistered)

    Ooo, I love the twist ending! Josh wasn't such a dufus after all! Great wtf.

  • htg (unregistered) in reply to mh
    mh:
    The *real* WTF here belongs to whoever let the developers set up and manage the database...

    In general, or just in this case?

    Any decent "enterprise" developer should know enough about databases to set up primary key constraints, indexes, foreign keys, check the data going into and out of the database, create efficient queries, functions, and so on.

    Maybe their work should be reviewed by a proper DuByA (hah, got the captcha in there) before being approved, but I don't see why developers should be separated from the database development, given that they're the ones who know what needs to go into the database.

  • anonymous (unregistered) 
    if ($ActivateJoshsWorkarounds) {
 print "Call Josh at 440-555-0221 and tell him what the following output says...\n";

  &FindAndFixBrokenDBStuff;
  exit 0;
}

    What's the & in front of FindAndFixBrokenDBStuff for? Does one have to precede function call with ampersand in Perl?

  • mattman206 (unregistered)

    440-555-0221?

    I used to live in Cleveland and recognize the 440 area code. Perhaps this is Alex's number?

  • Cloak (unregistered) in reply to htg
    htg:
    mh:
    The *real* WTF here belongs to whoever let the developers set up and manage the database...

    In general, or just in this case?

    Any decent "enterprise" developer should know enough about databases to set up primary key constraints, indexes, foreign keys, check the data going into and out of the database, create efficient queries, functions, and so on.

    Maybe their work should be reviewed by a proper DuByA (hah, got the captcha in there) before being approved, but I don't see why developers should be separated from the database development, given that they're the ones who know what needs to go into the database.

    You are right they should know. And sometimes they even think they do. When I think that over 50 % of databases in an international environment are made out of fields and tables in a complete language mix, poorly designed, vqrchqr(1) columns, char colmuns where really not needed, vqarchars instead of ints, without PKs or FKs, and a single table making up the entire database. And then try to tell these people that they are creating an unbelievable mess (after all it's their company that pays you and they for sure make sure that there is work even in 20 years). You may for a while remain diplomatic but then nothing happens since "it works, anyway". And the review by the DBA will just be ignored: takes too much time and costs too much money. Hardware is so cheap today, it's easier to add another server and there you are.

    Should-bes are nice but reality looks different.

  • root@thefair (unregistered)

    mmm...have much empathy - but try it without CVS & the organ-grinder messing with live code (and insulting you at the same time via First Class chat) while you're trying to get a CMS sorted!

  • (cs) in reply to anonymous
    anonymous:
    if ($ActivateJoshsWorkarounds) {
 print "Call Josh at 440-555-0221 and tell him what the following output says...\n";

    &FindAndFixBrokenDBStuff;
exit 0;
}

    What's the & in front of FindAndFixBrokenDBStuff for? Does one have to precede function call with ampersand in Perl?

    In older versions of perl the & was used to denote a function call. If you use parenthesis today, the & is optional. Personally, I abhor the old usage.

  • (cs)

    I was interviewing for a job and the tech lead told me "Primary keys place unnecessary constraints on you that can better be handled with your code." I laughed at his joke. But he wasn't joking.

  • (cs) in reply to mattman206
    mattman206:
    440-555-0221?

    I used to live in Cleveland and recognize the 440 area code. Perhaps this is Alex's number?

    Can't be; it's not a real phone number. No real phone number in the U.S. has the 555 exchange; it's reserved for use in films and TV and the like so that viewers don't call the numbers they see or hear in movies and harass people.

  • GrahamS (unregistered)

    It's a classic horror movie twist: the victim manages to lock themselves away from the maniac, only to discover they've locked themselves in a room full of maniacs that the perfectly sane guy outside was trying to warn them about.

    cue long dolly zoom on victim's face, to quick fade out and lots of blood-curdling screaming

  • SomeCoder (unregistered) in reply to htg
    htg:
    mh:
    The *real* WTF here belongs to whoever let the developers set up and manage the database...

    In general, or just in this case?

    Any decent "enterprise" developer should know enough about databases to set up primary key constraints, indexes, foreign keys, check the data going into and out of the database, create efficient queries, functions, and so on.

    Maybe their work should be reviewed by a proper DuByA (hah, got the captcha in there) before being approved, but I don't see why developers should be separated from the database development, given that they're the ones who know what needs to go into the database.

    That's true. I have to setup database stuff all the time. Any decent developer should know how.

    That said, it's nice to have a DBA whose job it is to do those kind of things and regular stored procs, access, etc.

    I liked this WTF. The real WTF was NOT Josh which was a nice twist on the tired old story of taking over for an incompetent moron.

  • Stephen Cochran (unregistered) in reply to Someone You Know
    Someone You Know:

    Can't be; it's not a real phone number. No real phone number in the U.S. has the 555 exchange; it's reserved for use in films and TV and the like so that viewers don't call the numbers they see or hear in movies and harass people.

    Oh, really? Dial 555-1212 and see what happens. And 1-800-555-1212 is great for finding 1-800 listings for companies.

    Yes, the 555 prefix has long been reserved for "fictional" use, but they are staring to phase that down to even a smaller range now (555-0100 - 555-0199, I think). Sounds like they are planning on bringing more 555 numbers on line.

  • (cs) in reply to SomeCoder
    SomeCoder:
    That said, it's nice to have a DBA whose job it is to do those kind of things and regular stored procs, access, etc.

    After years of dealing with crummy DBAs, I just regarded them as bottlenecks and did whatever I could to work around them. A competent DBA is invaluable though. I can tell someone "Here is the information I'm passing to you and this is what I need back". I go write the code around it and they give me a black box that does it.

    You need to know what's going on behind the scenes but you don't have to do it.

  • sig (unregistered)

    I don't get it. How come Josh had to create workarounds for a production release? After all, if the upgrade is utterly broken and segfaults on install, why on earth would the production team accept that? They should probably do a complete rollback and make the developer's lives a living hell until the issue is resolved.

    Kudos to Josh though, hope he found a better workplace!

  • Random832 (unregistered) in reply to sig
    sig:
    I don't get it. How come Josh had to create workarounds for a production release? After all, if the upgrade is utterly broken and segfaults *on install*, why on earth would the production team accept that? They should probably do a complete rollback and make the developer's lives a living hell until the issue is resolved.

    Kudos to Josh though, hope he found a better workplace!

    Probably the dev team managed to push the blame onto him - "it breaks on install, therefore it must be an install problem."

  • yummy (unregistered) in reply to Someone You Know
    Someone You Know:
    Can't be; it's not a real phone number. No real phone number in the U.S. has the 555 exchange; it's reserved for use in films and TV and the like so that viewers don't call the numbers they see or hear in movies and harass people.
    Only the range 555-01xx is reserved. All others are [potentially] valid.
  • AdT (unregistered) in reply to Random832
    Random832:
    This is why descriptive names sometimes don't pay - idiots get defensive when you call their stuff "broken". better to just quietly fix it in a piece of code with an obscure name.

    You'd think so, but one of my coworkers has been sent to the work at the gulag^W^W one of our customers and stumbled upon an easy to fix bug, so he just fixed it and committed it. Not much later, he received an e-mail where the original developer heavily chastized him for making "spurious changes" to his sacred code claiming that this could break all kinds of stuff (well, for one, it was broken before).

    Lesson learned: Don't fix bugs in other peoples' code.

    By the way, this attitude is not unusual at this place, and the general quality of their software is just what you would expect to obtain from developers who don't appreciate it when bugs are simply fixed.

    The code is also ripe with many an x-thousand line FunctionThatTriesToDoEverythingYouEverWant With20TimesTheCodeASaneDeveloperWouldNeed AndUnfortunatelyFailsBecauseItIsFullOfBugs AndTotallyUnmaintainableSpaghettiCode.

  • htg (unregistered) in reply to Cloak
    Cloak:

    You are right they should know. And sometimes they even think they do. When I think that over 50 % of databases in an international environment are made out of fields and tables in a complete language mix, poorly designed, vqrchqr(1) columns, char colmuns where really not needed, vqarchars instead of ints, without PKs or FKs, and a single table making up the entire database. And then try to tell these people that they are creating an unbelievable mess (after all it's their company that pays you and they for sure make sure that there is work even in 20 years). You may for a while remain diplomatic but then nothing happens since "it works, anyway". And the review by the DBA will just be ignored: takes too much time and costs too much money. Hardware is so cheap today, it's easier to add another server and there you are.

    Should-bes are nice but reality looks different.

    If a developer can't think beyond a 2D "spreadsheet like" table for more complex data then they're certainly not "decent" in my book.

    On the other hand I have had to integrate with an externally developed database, and that was a mindfuck - no primary keys - apart from one table, foreign keys not really done (certainly no cascades), no documentation, varchar(1)s for yes/no, etc. So yes, I appreciate that people who are not qualified are let loose on databases and their work gets too far before review can correct it and their clients don't realise they've paid tonnes of money for shit. Of course the repeat business to keep the system running ...

    Sadly that's an issue with the corporate culture that doesn't realise the simple truth that a single good programmer who does things right can be worth 10 people who will create systems that don't scale, won't last, and fail regularly (oh, I'm not bitter here!). If you don't schedule and plan for regular code reviews for employees doing something new, then you'll be burned (captcha). If you're in an environment where this happens, then there won't be a DBA to do things correctly anyway, and certainly not the communications required to get the developer and the DBA talking to each other.

    Given how important a business' data is, setting someone onto the database who has no experience is absolutely foolish, and a result of people not understanding the vast number of different disciplines within software engineering. Then that same person does the website, and later that year all the data is grabbed via an SQL Injection and you are wondering why.

  • Joe (unregistered)

    I imagine a "dolly zoom" (http://www.en.wikipedia.org/wiki/Dolly_zoom) when Brian sees all the Segmentation faults.

    "to suggest that a character is undergoing a realization that causes him to reassess everything he had previously believed"

  • Matt (unregistered) in reply to akatherder
    akatherder:
    I was interviewing for a job and the tech lead told me "Primary keys place unnecessary constraints on you that can better be handled with your code." I laughed at his joke. But he wasn't joking.

    I wish I could say I have never been told that myself...

  • bd (unregistered)

    I'm getting a flashback to The Others.

  • bd (unregistered)

    I'm getting a flashback to The Others.

  • Andrew (unregistered)

    Smell that, its a turd of a PM or lead developer.

    I've been Josh before. Found a bug that the lead insisted wasn't and was programmed that way with good reason. The PM took the lead developer's position.

    One day right in the middle of a production run. . .boom. The entire process quits working.

    The bug was to give a network communication .25 seconds to complete then assume data had finished transmitting.

    I had predicted the crash 3 months out and was ignored.
    You go Josh!

  • Raedwald (unregistered)

    Developers who do not realise that in all cases a SEGV indicates a program bug? Brillant!

  • (cs)

    What kind of company doesn't have a development database against which its products are tested? That's the real problem in this story -- it sounds like only a production database existed. A bug that caused an upgrade to fail should have been caught by developers, not customers.

  • Also in 440 (unregistered) in reply to Matt
    Matt:
    akatherder:
    I was interviewing for a job and the tech lead told me "Primary keys place unnecessary constraints on you that can better be handled with your code." I laughed at his joke. But he wasn't joking.

    I wish I could say I have never been told that myself...

    Here's a hint from someone who's been there. If the leads also tell you that documentation is a waste of time, and that configuration values should be hard-coded because of "security" concerns, avoid working for that company at all costs, even if you're desperate for work.

  • (cs)

    Great WTF! Josh hereby is added to my personal "List of cool people".

  • Corporate Cog (unregistered)
    he can explain why he feels our databases contain broken stuff that needs to be fixed!

    Ah, this is the great question we all (except rock stars) need to ask ourselves. When making waves in a development shop, are we Josh or are we part of the crowd who thinks Josh is an idiot when he isn't?

    I always think I'm Josh, but I've been in the crowd.

  • Franz Kafka (unregistered) in reply to akatherder
    akatherder:
    I was interviewing for a job and the tech lead told me "Primary keys place unnecessary constraints on you that can better be handled with your code." I laughed at his joke. But he wasn't joking.

    It's still a joke. Just a question of what (or whom) you're laughing at.

    /muhahaha

  • AdT (unregistered) in reply to anonymous
    anonymous:
    What's the & in front of FindAndFixBrokenDBStuff for? Does one have to precede function call with ampersand in Perl?

    Usually not, but in some cases it can be used for disambiguation.

    package MyPackage;

sub print($) {
	print(shift, ", I say.\n");
}

&print("Hello World");

# is just like

print("Hello World, I say.\n");

1;

    Otherwise you'd have to say MyPackage::print, though that would arguably be more readable.

    You would also use the ampersand if you wanted to take a reference to a sub, or make a function call itself recursively.

    Captcha: smile (How can I when I have to use IE to post this comment?)

Leave a comment on “The Josh Workaround”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article