Probably the dumbest sentence I'll ready today.  

With all the caveats that their analysis is designed to look at trends over time and not the outcome of one game, the June 12 match-up between the US and England in South Africa will be a mini-test case for their theory.

US vs England -- A Soccernomics Analysis, EPL Talk

That Evo would win was pretty much a foregone conclusion.  The rest of the analysis is very good, particularly the prediction that votes from the exterior could really make a difference in the future.  I didn't realize it could be larger than some regions voting population.

Official results aren't out yet. But here's what we know so far about yesterday's election in Bolivia: Evo Morales won (as expected), and by about the margin predicted in polls (I explain below). MAS also won majorities in both legislative chambers, but only managed a 2/3 supermajority (so far) in the upper chamber. The autonomy referendums were a smashing success, winning massively almost entirely across the board

Pronto*

I originally posted this as a comment on Keith Casey's post about Software Development Failures.  I've tried to expand my thoughts a bit here.

Indicators of failure often stem from the practice of not properly maintaining a large codebase. In most organizations, the focus is on deploying code within a narrow time frame. That is, "ship it now!" The first items to be cut from the budget/schedule, if they were ever in there to begin with, are testing, documentation, and any perceived "slack". The temptation to get something done right now often wins out over getting it done right.  A company may, intentionally or not, reward developers who show quick progress, regardless of whether they are doing things right or working efficiently.

I think, and granted this is based on my own experience, that successful software projects are ones that pay attention to building the codebase right and maintaining it as well, doing things like:

• Proper testing, unit- or otherwise, but likely automated so that you can prevent regressions when you change your codebase.
• Documenting Code, phpdoc and at least API generated docs. I know when I'm looking at yet-another-framework, that good documentation and howtos/tutorials are the first thing I evaluate. Its why I hated my first exposure to CakePHP, but liked Solar and CodeIgniter. Even Drupal does a decent job of this, which is why so many can overcome/live with how its designed. Documenting a codebase is also instructional for finding/flagging deprecated functions, repeated code blocks, and planning what needs re-factoring, making it easier to bring new developers up to speed.
• Maintaining the codebase, doing the little things that only programmers might notice but can have an impact on how extensible, understandable your codebase is. Encapsulating code in classes/functions, laying out files in an understandable manner, separating View from Logic, going back and fixing the corners cut to release the project, etc.
• Using Versioning - I can't imagine working without it now. The challenge, particularly on a web site project, is getting non-technical users like designers to learn it and use it.

I don't think this is an exhaustive list, just observations from my own experience in inheriting 2 product code bases.