Large projects have many gatekeepers (that have feedback, sometimes conflicting), integration issues (I'll get to this one in a second), and scheduling issues (

Large projects have many gatekeepers (that have feedback, sometimes conflicting), integration issues (I'll get to this one in a second), and scheduling issues (this one seems to be arbitrary based on political deadlines). Consider the integration issues for this website. Multiple insurance companies, after decades of working in isolation (insurance companies were early to utilize computing), are now expected to bend their offerings into the lowest common denominator between themselves and other companies (so a computer can do analysis on them). Think about the headache that would be for managers, programmers, and domain experts. All with political taskmasters cracking the whip with unrealistic expectations. On top of that, bad code means that money might be lost by third parties. This code has high lawsuit potential (no matter how well agreements are written). My point being, public or private, this project was destined to be a difficult one. I want to expand on a simple point of government and large corporation programming that might not be obvious to the casual observer. There is a lot of inertia in the system. I've found bugs older than me (in code that runs nightly). I once worked for a company that had code written in the 60s still going (thankfully I wasn't on that project). Old code isn't going anywhere soon, and trust me, you don't want to deal with it. Even though you can make a career out of it, a lot of effort is needed to make even the smallest changes. I don't care how good a programmer you are, if your tools or environment suck, you're in trouble. And this is one of those cases where being elite doesn't beat above average with experience. Not even close. I'd much rather the person who can say "We did something similar back in '95, and it caused problems in these places" than the best programmer on the planet. Because for these types of jobs, the best programmer on the planet is usually the person who knows the system best. Any team of people, no matter how talented, will be spending the majority of their time understanding what is in place. Note that I haven't gotten into the procurement process, which can turn a difficult project into an impossible one. But that's a problem that also lacks a silver bullet, and is a larger discussion.