I've lived in a number of areas of the country. The common political element that rose above all the rest is the differences between the large cities and the rural areas. So, instead of a split by area, make each large city -- San Francisco/San Jose, Los Angeles/Hollywood -- its own state. (What to do about Sacremento? Is it a city or a condition as the State capitol?) Then City interests could be served by the City States, and the rest of the state with its agriculture base would be able to set policies and law for their own.

Other states/areas could be split the same way: Massachusetts, Illinois, Washington DC area, Michigin (peal Detroit from the rest of the State), New York/New Jersey/Connecticut...and the list goes on. We could combine small states into large states -- think Providence Rhode Island versus the rest of the State.

I'm not sure the Democrats would go for this.

Everyone is missing the point. The space program was done one step at a time, finishing each step before moving on to the next. Yes, this is "waterfall" thinking, but in the space program it was the right way to do it. Properly done, the agile approach could also have been used in the moon program, as long as the result is that the final push is composed of fully-tested and vetted pieces. (Could it be that the agile approach was indeed used? People closer to the facts can answer that.)

The reason to have multiple contractors is to allow development of different parts to be done in parallel. The key to success with broad development is a really, really good architect specing the interfaces, and each people/group showing that their stuff works as specified at the interfaces. Then integration testing becomes a manageable exercise. This includes performance metrics -- at the interfaces. Was that done here? I highly doubt it.

And the Affordable Care Act missed a number of elements that would have made health care affordable. It's isn't about insurance, it's about the total experience. And Congress bungled it. At least, those people in Congress who were allowed to contribute did. What was wrong with stepwise refinement?

"Everyone knew what was in it, regardless of what Rush Limbaugh told you." Strange, what I recall during the run-up to the passing of this piece of art was the Democratic Speaker of the House saying "We need to pass it to find out what's in it." And we are finding out.

"But people who send e-mail imply consent..."

I'm a long-time Google Apps user, and my company's domain is on all mail receipents' mail, not "gmail.com". So how can you have implied consent when the sender doesn't know that the mail is being sent through Google?

Are Obamaphones already unlocked? If so, what is "the government" paying for the phones? The associated service?

OK, I have QA training in my background as well as programming skills, so apply appropriate amounts of salt: some of the most interesting blunders in design, and blunders in implementation, are exposed when a good technical writer tries to makes sense of what s/he sees, and fails. In the process of trying to teach others how it all works, all the warts, cracks, crocks, and kludges are exposed in all its glory. What doesn't make sense in a manual will most likely not make sense in the real world. Think of it as scaffolding for the mind. "According to the specification, when I do THIS then X is supposed to happen; instead Y happens." And so forth.

When I was in a large programming group in the 70s, I was the guy sitting at a Wang word processor, banging out design specs and cursing some of the square-heads that couldn't seem to design their way out of a paper bag. When my company decided they wanted to build their own replacement computer for one they had been buying for years, they turned to me to "reverse engineer" the computer -- including all the proprietary extensions and additions -- so the hardware group would have something to design to, and the SQA people to test the implementation against.

Actually, it's an old story in Engineering. When you try to explain something, you see holes that you were blind to for days, months, even years. It's an "Aha!" generator.

There is a benefit that no one has mentioned yet: HFT can cause the market for a stock to oscillate out of control very, very quickly, and that oscillation can disrupt the trading in the stock. The "circuit breakers" the NYSE put in to damp out-of-control oscillations are pretty much defeated by HFT. Further, HFT disassociates the value of the stock itself from the perceived value created by short-term movement in the market, and so affects the capitalization of a company trying to do business. HFT is also a way to quick ruin, if the algorithms used are not tuned carefully enough -- and particularly if two trading algorithms get into harmonic resonance: think Galloping Gertie, the Tacoma Narrows Bridge in 1940.

"I write excellent product specs" -- are these product specifications sufficiently detailed to have a consulting Software Quality Assurance person be able to test each feature of the product? Sufficiently detailed so the multiple people you hire can seamlessly do integration testing? What scaffolding do you provide for each of the developers? Do you have the same "source control" of your specifications as you do for the code generated from them? How do you handle "feature creep"?

"Bug tracking and source control" -- Do you have staff or contractors who confirm the bugs? And how do you handle regression testing during development and subsequent maintenance? How about code reviews? Who handles customer service queries?

"Empathy for developers" -- demanding bug-free code without the tools and processes to give the contract developers a fighting chance? How well do you anticipate corner cases in your products, so you can include them in your specification? What practices do you insist on to catch bugs early in the product development cycle?

"...hire someone full-time...know a lot of languages and be proficient in all of them...can't afford to pay someone $100k/year" -- Sounds like a version of the Universal Specification: "I want everything, now for, $1.98." As for pay, that one is easy: make him a partner, and he earns from the bottom line just like you do. You will probably have to take a bit of a pay cut to attract what is essentially a do-everything maintenance programmer, not exactly the career track that anyone with the type of experience you are looking for would choose. Have you looked at the pool of experienced programmers? There are quite a few who have been put out to pasture because they don't have the "zing" in their resume that most [In]Homan Resource people look for. Learning languages is a skill easily picked up. Learning how to un-muddle code written my others is an art, and people skilled in the art of decoding a mess are much harder to find, let alone identify.

Transition? One possibility is to find a contractor highly skilled in maintenance programms. If he works out, offer him a partnership.

As for the attitude that any piece of software can be completely bug-free: that's a holy grail. The ADA Programming Language was invented to try to provide an underpinning to achieving the holy grail -- when was the last time you heard about it seriously? Several research-based languages have been developed that purport to "prove" that they are correct...but watch what happens when an unanticipated corner case hits the code. Many of the advances in languages and compilers focus on finding easy and trivial problems quickly, so a programmer doesn't have to spend time finding and fixing them. (Scripting languages, particularly those that compile "on the fly" such as TCL and most shell scripts, point out the advantage of a proper compilable language; you lose some flexibility, but the overall programmer cost is far lower than tripping over mistakes one at a time, particularly if the programs run are measured in minutes and hours.)

Your business model will need to change. Count on it.

...that would take documentation of the plugboard wiring of the old 400 series "accounting machines" and produce source that would work exactly the same as the accounting machine, give 80-column card images for the data. It wouldn't emulate any cross-connects to other tab equipment (sorters, punches, interpreters) but it did a wonderful job of moving plug-board programming to the more modern computers (360, in particular). Anyone know where that software might be? As I recall, it was on a micro-spool of magnetic tape originally, purchased at user group meetings. Time to google...nothing so far...

One of the issues that always comes up when talking about H-1B is that employers say they can't satisfy their needs with the talent already available. So, how about adding the requirement that any H-1B applications require the company post a "Help Wanted" ad in a national database for three months before the application is approved. Let's see why companies don't like citizen talent. Let's see how citizens can fill those jobs.

If your school anticipated the problem, you can find the solution. First, see if your dorm has a segregated study area. At the school I went to, that study area was in the basement, down the hall from the laundry room -- the idea was that you should start some clothes washing, study, dry, study, fold, and be done. The room was soundproofed...but the lack of echo and noise unnerved some people, but I loved it. Also, there was a lounge in my dorm where -- most of the time -- you could find peace and quiet. Other people suggested the library as a place to study. The solutions don't have to cost money.

Regarding bridges/roads and tolls: One of the rationales for keeping tolls on roads and bridges is to collect money to maintain the roads/bridges once they are paid off. I've seen this reasoning used in three states, and in all cases the tolls were increased "because the cost of maintaining the roads keeps going up." In Cook County IL, the real reason the tolls were kept on is because sub-standard work had to be torn up and re-done -- multiple times. The reason the work was sub-standard is left as an exercise to the reader.

I've never lived in a state where the tolls were retired and the booths torn down.

Dig a little deeper, and you find out that the governments appreciate how tolls free up general revenue for other spending.

If you have ever been involved with regulated radio, the regulation " Carriers must approve of the use of each and every one of these boosters" makes perfect sense.

The introduction of a repeater into a cell system means that the engineering of the cell boundaries can be affected. Now, for boosters that are used in building that shield the RF, there is little engineering that needs to be done -- you are essentially extending the antenna outside the shield. (And you can get repeater antennas without boosters that do the same job, and I suspect they are *not* covered by this regulation.)

When you have an active repeater, that means the cell signals from the provider can be relayed as well as the signals from your cell phone. With microcell design, this can play hob with the clearances, so that a phone will see two cell site courtesy of your repeater.

I'm not an expert on cell systems, but I remember some of the arguments used to keep people from using cell phones from airplanes.

This reverse Polish language was not a "mainstream" language, but for astronomers, it was perfect for telescope automation. FORTH was also used in other robotic things. I was really surprised that FORTH wasn't included on anyone's list. In fact, how many of you have ever heard of FORTH, let alone did any programming in it?

They've gone into plaid. http://www.youtube.com/watch?v=mk7VWcuVOf0