Joys of Outsourcing



  • I was hired on at a company to take over a project that had been contracted to a team in India. The project has apparently languished for over a year. After two weeks of triage and aggressive refactoring, its on the verge of heading off to the customer for testing. In these two weeks, I've come across any number of WTFs, but a few are just facepalm inducing...





    class CommonFunctions {

    public static bool CheckFileExists( string file ) {

    if ( File.Exits( file )) {

    return true;

    } else {

    return false;

    }

    }






    Unfortunately, the project ties into Microsoft Office Communications Server as well, so this is far from the worst... Check out the documentation for the Microsoft.RTC.Collaboration namespace here. It's not cryptically sparse at all... And the whole Begin/End IAsync pattern isn't susceptible to abuse, either...


    I traced the code for a significant component of the project, and followed it through a chain of more than a dozen IASync callbacks. Any of those calls could fail, and short circuit the entire process. If the process for some reason failed, a global flag that blocked the entire program would remain set indefinitely (it was unset at the very end of the chain of callbacks). To top it all off, this Jenga construction was initiated from the bowels of a harmless-looking default constructor... And all state variables were declared as static at class level, so Zombie Jesus help you if you ever spun up two of this component.



  •  Outsourcing as a way to save money: you get what you pay for!



  • @Megaman22 said:

    And the whole Begin/End IAsync pattern isn't susceptible to abuse, either...

     

    I'm not sure what you mean here.  Asyncronous IO is a good thing and very common in .Net. 



  • @frits said:

    @Megaman22 said:
    And the whole Begin/End IAsync pattern isn't susceptible to abuse, either...
    I'm not sure what you mean here.  Asyncronous IO is a good thing and very common in .Net. 
     

    Only if you understand how to use it. Based on what Megaman showed us I doubt the original developers do.

    Async is very tough for some people to grasp. In Silverlight (and all browser-based frameworks, I think, but Silverlight is my specialty), all web service calls are async, which means you call the web service and it returns immediately and an event gets raised when the work actually completes. I've seen enough things posted on the Silverlight forums/StackOverflow/etc. where people who don't/can't/won't/refuse to understand async would rather spend the time trying to come up with a way make web service calls synchronous rather than spend the (lesser) amount of time (and frustration) required to just learn how to do async correctly. Factor in that these same devs usually abuse threading (without any conceptual understanding of threading) and that in Silverlight/.NET an exception is raised if anything other than the main thread touches the UI, you get code so bad it would even make Adobe developers cry.

     


  • 🚽 Regular

    @mott555 said:

    I've seen enough things posted on the Silverlight forums/StackOverflow/etc. where people who don't/can't/won't/refuse to understand async would rather spend the time trying to come up with a way make web service calls synchronous rather than spend the (lesser) amount of time (and frustration) required to just learn how to do async correctly.
     

    We had a senior dev actually try this very thing. What ironically happened was, in the process of bending over backwards trying to make an async process synchronous he wound up learning how the async process really worked, and had a Eureka moment, realizing that what he was doing was utterly stupid and that async, truly, wasn't as much black magic as he initially thought. Event-based patterns are often ugly, but you can usually hide that stuff by wrapping your async calls around a simple function that is passed whatever data you need, plus the proper complete and error callbacks so that you confine the ugly event handlers in one package. At that point, with a little explanation, async calls are a pretty easy concept to grasp for all but the densest programmers. The code is still a bit more convoluted than synchronous calls, of course, but you at least still have a flow to follow, and it's usually easy to debug (much easier than trying to fit a square peg into a round hole by making an async process synchronous, anyway).


  • Trolleybus Mechanic

     



  • @Lorne Kates said:

     <AJAX 101 image>

     

    Lorne, your image is concise, helpful, and correct.  What were you thinking!?

    (Seriously, though: somewhere along the way it's really disturbing that people are not taught how interrupts work.  An 'event' by any other name and all that jazz.)

     


  • Trolleybus Mechanic

    @too_many_usernames said:

    Lorne, your image is concise, helpful, and correct.  What were you thinking!?
     

    Sorry. I'll try harder. Umm-- penis?



  • @Renan said:

    Outsourcing as a way to save money: you get what you pay for!
    But the offshore team finished the project quickly and cheaply. It's the local guys who are taking forever working on it. Clearly I need to outsource more. By the way does anyone have a comb, I can't get my hair down.

     



  • @DOA said:

    By the way does anyone have a comb, I can't get my hair down.

     

     

    Did you hear the one about the impotent duck?  He couldn't get his down up.

     



  • @da Doctah said:

    @DOA said:

    By the way does anyone have a comb, I can't get my hair down.

     

     

    Did you hear the one about the impotent duck?  He couldn't get his down up.

     

    Did you hear the one about James Brown, when he had a fall in the old folks' home?  He said "Help, I've fallen and I can't get down!"




  • I take it that File.Exits() is an extension method doing something better than File.Exists() can manage :)



  • @pinkduck said:

    I take it that File.Exits() is an extension method doing something better than File.Exists() can manage :)
     

    It solves  the halting problem if the argument is an .exe.



  • @pjt33 said:

    @pinkduck said:

    I take it that File.Exits() is an extension method doing something better than File.Exists() can manage :)
     

    It solves  the halting problem if the argument is an .exe.

     

    Implementation is left as an exercise for the reader.

     



  • @Lorne Kates said:

    <AJAX 101>

     

    Where is that image from originally?  It looks like there's more to it (maybe out of a book?), and if the rest is as good as this example then it's a reference I could use.



  • @Someone You Know said:

    @pjt33 said:

    @pinkduck said:

    I take it that File.Exits() is an extension method doing something better than File.Exists() can manage :)
     

    It solves  the halting problem if the argument is an .exe.

     

    Implementation is left as an exercise for the reader.

     

    C++ implementation: (with race conditions and no error checking, and assuming the filename doesn't contain a quote mark)

    bool File_Exits(std::string filename)
    {
        std::ofstream tempfile("/tmp/donothing.c");
        tempfile << "int main(int argc, char **argv) {return 0;}";
        tempfile.close();
        std::string command = "gcc /tmp/donothing.c -o \""+filename+"\"";
        system(command.c_str());
        return true;
    }
    


Log in to reply