Why in the world would a change advisory board think it knows more than ANY company putting out an update?

if you're looking for average lifespan of a country, you have to actually look at countries that are no longer around. since ones that are alive you have no idea of how long they will continue to be alive. maybe one day, maybe a thousand years. if all the countries you sampled are still around then your sample size - as far as survival time is concerned - is effectively zero. you could assume an exponential probability distribution and try to compose a maximum likelihood estimate based on they all will live longer than they have been around, or on average their expectation is twice as long as they've been around, but still... why make such extrapolations when you can use actual samples from countries that are no longer around?

you can think of it kind of like an ant colony; it lays pherome trails.

data structures would be kind of like this:

neighboring_devices table:
[neighboring_device][last_gps_coordinate][last_connected][single_hop_recieve_lag][single_hop_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

communicating_devices table:
[communicating_device][last_gps_coordinate][total_recieve_lag][total_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

route_stats table:
[communicating_device][neighboring_device][total_recieve_lag][total_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

packet header, forward info:
[source_device][destination_device][source_last_gps][destination_last_gps][sent_time][sent_from_last_hop_time]

packet header, feedback info (routing data back-propagation):
[send_back_from_last_hop_time][send_back_single_hop_time]...

link status will have to be propagated through the neighbors - false. for instance, they can use an acknowledge protocol to passively learn link status
but then geometry will be utterly irrelevant - false - geometry - do you mean topology or geolocation? either way topology is relevant, obviously, and geolocation is relevant, insofar as it can provide a good guess when topology is unknown. only way to make it irrelevant is to make topology always known, and that's impossible since the topology is dynamic.

no, it will find a tentative shortest path, in terms of latency. and that will improve over time, and if you're filling it up, the latency will go up, so it will start falling over to a different path since now a different path will have lower latency...so now it has two paths that it splits the packets between so as to balance their latency...and then maybe it gets a third, or drops down to one when traffic dies down. but now someone turns their cell phone off, so now it routes around that... etc. it only uses what it needs, and it adjusts what it uses and how it gets routed to adapt to changing needs, changing traffic patterns, and changing network topology.

now the next level to this, for mobile ad-hoc networks, would be using gps data as a pre-fix to the "source" and "destination" address, and if it can't find the actual device, it routes to the known destination with that reduces the gps distance at the greatest rate. then it really becomes a path-finding algorithm with obstacles.

i though of this years ago. probably a decade ago. there is no packet enveloping. the header is fixed length:
[source address][destination address][time initially sent][time from last hop]
the clocks on the units must be synced highly accurately, but there's a way to do that democratically over the same channels, using unused bandwidth. also unused bandwith can be used to exchange hash data to optimize routes.
then the thing you want to figure out, at each point, is, given the destination address, what "port" to send to.
so you have a hash of destination addresses, and each one has a list of ports and their respective latencies, calculated from previous transmissions. just try the best path first. it's like "pruning" in a mini-max algorithm.
i dont feel like going in depth on the details of the algorithm for getting time statistics and dynamically updating them, but i hope you can see that once you start from first principles and work forward, the answer writes itself.
now i designed this for infrequent network changes, where each unit was a physical "router" and thus had a fixed number of "ports". in a mobile ad-hoc network, network changes would be much more frequent and the number of "ports" very dynamic. so the fix for this is to identify each "port", not with a number, but with the unique device id of the device at the other end. and then as devices go out of range you can choose to retire them like you retire a cache line.
so there you have it, basically. the basic data structure layout of a highly scalable highly dynamic, self-repairing, self-optimizing network. the rest is just a bunch of simply algorithms for updating the data in the data structures.

having two desktop monitors will significantly increase your productivity.
i have three. they all get plenty of use.

that last part is obviously false.

This is how redistrcting should be done: with a computer algorithm that mathematically guarantees fairness: https://raw.github.com/happyjack27/autoredistrict/master/README.md

all this talk about gerrymandering. the solution is very simple, technologically speaking. here it is. open-source this:
block and length data can be taken from a standard dime file, which i presume any municiplality has. the census data, well i'm sure they have it electronically, cause hey, they draw districts. so getting the geolocation dataset is not a problem. you still have to add in code to make sure the districts are contiguous, though. b

//QUANTITIATIVE GERRYMANDER CALCULATOR - //for use in heuristic optimization (e.g. genetic algoritm / swarm ) for computer-automated redistricting.
class District {
    Vector blocks;
    double getEdgeLength() {
        double length = 0;
        for( Block block : blocks)
            for( Edge edge : block.edges)
                if( edge.block1.district != edge.block2.district)
                    length += edge.length;
        return length;
    }
}
class Block {
    int district;
    double population;
    double prob_turnout;
    double[] prob_vote = new double[num_parties];
    Vector edges;
    double[] getVotes() { //TODO: get random variables of the vote distribution given the statistics for the block.
    }
}
class Edge {
    Block block1;
    Block block2;
    double length;
}
public double[][] getRandomResultSample(Vector districts) {
    double[] popular_vote = new double[num_parties]; //inited to 0
    double[] elected_vote = new double[num_parties]; //inited to 0
    for(District district : districts) {
        double district_vote = new double[num_parties]; //inited to 0
        for( Block block : district.blocks) {
            double[] block_vote = block.getVotes();
            for( int i = 0; i most_value) {
                most_index = i;
                most_value = district_vote[i];
            }
        }
        elected_vote[most_index]++;
    }
    return new double[][]{popular_vote,elected_vote};
}
public double[] getGerryManderScores(Vector districts) {
    double length = 0;
    for(District district : districts) {
        length += district.getEdgeLength();
    } //TODO: calculate kldiv as http://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence , where p=popular_results and q=election_results (q is used to approximate p)
    double kldiv = 0;
    for( int i = 0; i < 100; i++) {
        double[][] results = getRandomResultSample(districts);
        double[] popular_results = results[0];
        double[] election_results = results[1];
    }
    return new double[]{length,Math.exp(kldiv)}; //exponentiate because each bit represents twice as many people disenfranched
}

for closed: *if you actually look at the stats of open source code, you see it's primarily written and maintained by a small handful of very good and very productive coders. *elections are war. and war is by nature closed-source. *programmers are like 99% democratic, since the brain structure for programming and thinking like a democrat go hand in hand. i don't think they want to give the fruits of their intellectual labor to the intellectually lazy. that's kind of anti-darwinian. *it's pretty much certain that RNC will try to sabotage it if it's open-sourced. after all, that's essentially their modus-operandi. for open: *benefits of open sourcing is not to be disregarded. i'm sure there are peopel who can come up with better probability models and what not. *open-sourcing the code is not the same as open-sourcing the data. *the RNC already has very high voter turnout. it probably won't be that much of a benefit to them, certainly not in proportion to the benefit to the DNC, which has low voter turnout.

"what we are doing and how we have pulled it off" is not necessarily very relevant. there may be better ways to do things than the way you've been doing them. in fact, the alternative (that there aren't) is nearly impossible. don't assume that he/she can only learn from you just because they're new to the team. it's almost certain that there are also things you can learn from them. perhaps its wrong to thing in terms of "good" or "bad" code, and more proper to think of it in terms of differentials: "better" or "worse". so then what constitutes better? the most important thing in all writing, code included, is organization. if things can be reorganized to reduce duplication, to make things easier to find, to make it easier to maintain, etc. well then, that's better. as programmers, like doctors put the patient first, we should put the technical operation first. screw egos. it's broken, fix it. it's better to do it some other way, do it that other way. etc. if, on a separate issue, the person just is being disrespectful, well that has nothing to do with code. sometimes its hard to tell the difference, though. in any case my main point is, don't put him off just because he's a new guy, or just because you've been doing something one way for a long time, or just because you're egos bruised. what matters is that the code works well and is flexible and well organized and is easy to maintain. and if you want him to be a valuable asset, you should be encouraging him, not discouraging him. abraham maslow's on management. he sounds self-motivated and driven to constantly improve. that's great! you should encourage that! mastery, self-direction and purpose are the primary motivators and it is a godsend to find talent coupled with motivation like that!

pfff... i designed a much better autothreading language, much better, much simpler, much more intuitive, and allows for data-parrallel threading. a long time ago, too. https://sourceforge.net/projects/tsunamiprogramm/