Myrtis joined Initech as their first on-staff software developer. Up to that point, Initech outsourced all the software development on their payroll/billing system. The contractor kept raising their rates, Initech’s business needs kept growing, and eventually they decided it was time to hire an in-house developer.

Which meant Myrtis got to inherit all of that outsourced development. All that code, all of which had some pretty significant financial implications if it contained any bugs or errors, all developed by a third-party to a third-party.

Imagine, for example, that you need to round to the nearest quarter. That is to say, 1.12 rounds to 1.00, while 1.19 rounds to 1.25.

public static double RoundToQuarter(double input)
{
    int start = Convert.ToInt32(input.ToString().Contains(".") ? input.ToString().Split('.')[0] : input.ToString());
    double dec = input - start;

    if (dec < 0.13)
        dec = 0.000;
    else if (dec < .38)
        dec = 0.250;
    else if (dec < .63)
        dec = 0.500;
    else if (dec < .88)
        dec = 0.750;
    else
    {
        dec = 0.000;
        start += 1;
    }
    return start + dec;
}

The hand-coded break-points for the rounding are almost acceptible, since there are only four of them. You couldn’t rely on one of the built-in rounding methods to handle that specific case.

Speaking of built-in rounding methods, why use that at all? If you want the integer part of a number, you can just ToString it and split on ., assuming your software is never going to run anywhere they use , as the decimal seperator.

The real, WTF, though, is knowing that this is financial data. Even though we’re rounding to a fairly low precision result, all the inputs and all the outputs are double. You just know all the currency values all through this application are doubles.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!