• Antares686 (8/27/2012)


    This is great if your source is 10 million lines of code, but they still have to trace out the changes that caused the failure via the coders who developed said changes. That said do the coders not compile their own code to test the same thing before they submit, I mean I launch my code after almost every change I make to ensure compiles and there are no errors/warnings (I'm a bit of an obsessive on this), thus I am doing the exact same thing they are calling great,

    [\quote]

    You're missing the change. If 25 developers make changes, how do you know they haven't caused each other problems? That's what this is designed to help find. There are plenty of developers, especially across staff changes, that might not recognize warnings as problematic. I'd hope they catch compile errors, thougt.

    I do like to catch mistakes early, especially while me or the other developers still have the changes fresh in their heads. I don't think Inuit has cornered the market on this method

    The idea here is to catch mistakes early and feed them back to the developers within 30min or so when things are fresh in their minds.

    This doesn't necessarily make better code. That all depends on the developers, but it does give you a way to reduce costs and potentially make better code by finding issues quickly. You could just get code out quicker, and it still be crap code.