Yep, sure. I mean, in all you can find yourself refactoring forever. There's always room to improve something, ya know? I think they're doing a great job of fighting off the huge influx of users, bots, and attackers, though.

I've worked on a similar problem recently in javascript for my startup. In my case I needed to pick the most prevelant non dark color. So a bit different but some of the same principles should apply. My steps were as follows: 1. Get the colors 2. Get the weight of the colors (how prevelant each one is) 3. Convert RGB over to hex equivelant 4. Perform a luma check to get a brightness value for each color

From there you should be able to pick your color based on your criteria. Here are some of the utility functions I used.

function lumaCheck(c) {
    var c = c.substring(1);
    var rgb = parseInt(c, 16);
    var r = (rgb >> 16) & 0xff;
    var g = (rgb >> 8) & 0xff;
    var b = (rgb >> 0) & 0xff;
    var luma = 0.2126 * r + 0.7152 * g + 0.0722 * b;
    return luma;
}
function componentToHex(c) {
    var hex = c.toString(16);
    return hex.length == 1 ? "0" + hex : hex;
}
function rgbToHex(r, g, b) {
    return "#" + componentToHex(r) + componentToHex(g) + componentToHex(b);
}

In general what you'd probably want to do is get the most prevelant color. Get its brightness (lumaCheck). Then get the color with the furthest luma value away from the picked color in your color set. You can tweak your function to decide between weight & luma value until it's satisfactory. With your example the primary color would be derived from your data result and your compares against the backgrounds, I suppose.

Interesting. I haven't engaged in such a large group mob session before. If we pair up at my company it's usually two people - sometimes three. It does prove useful for some scenarios such as those where we have one dev developing a client and the other dev developing the server component simultaneously while a third spot checks.

Yeah no doubt. From what I understand they started this project as a learning experience in college or something. I skimmed through some of their code and from what I can see I would focus on a few things:

1. Abstract business, data, and infrastructure logic into separate projects. This will make writing for scalability easier in the future if they decide to move to a queue driven pattern or something. It will also make the code easier to read and more modular.
2. Remove left over VS template code.
3. Move scripts/styles/etc to a CDN.
4. Use some sort of DI/IoC with Autofac, Structuremap, etc.
5. Get ready for a load balanced environment. If they use something like azure wep apps or azure cloud services this is pretty easy. Even SignalR has a single line configurable backplane with SQL, Azure Service Bus, or Redis. It's actually a fairly cheap solution.

It looks like they sort of do. If you look in the UnitTests.cs file there's a few tests in there.

https://github.com/voat/voat/blob/master/Whoaverse/UnitTests/UnitTests.cs

But it doesn't seem like it's something they do consistently (last commit was May 19).