269 and Peer 1

So there is some discussion this year of a 269-269 electoral college tie. The level of thinking involved, though is shallow. This is an important lesson in disaster planning. Peer 1, and their customers, didn't plan well. You can read the story here. The connection will be come clear in a paragraph.

The quick summary is that Peer 1 relied on the fuel pumps of the building (75 Broad Street) that were in the basement near the fuel tanks. But those fuel pumps failed when they were flooded by Hurricane Sandy as well as a water main break. They went to heroic efforts with a manual bucket brigade, and even avoided downtime (it was so close that some customers chose to shut down to prevent data corruption). However the failures in planning became very clear. Their generators could not operate so long (a week) without downtime. They clearly didn't consider a flood. They were only prepared for a power outage, like a substation explosion. Nothing more. No extended outages, nothing. From the description it isn't even clear they had two generators. This comes from failure to consider the possibilities, and a complacency about the current model.

In a 269-269 tie, Congress votes on the president. But there are other possibilities. An Elector is not legally required, let alone automatically counted, to vote for the candidate he or she is pledged for. If there is a 269-269 tie, the first thing that will happen is that the winner of the popular vote will pressure electors for the other side to switch. If just one switches, it is over. Look for the Democrats to do that this time, because in a 269-269 tie, they are most likely the winner of the popular vote, and more importantly they stand to lose in the house. So even if they lose the popular vote, look for another argument.

When preparing for the unknown, you have to think beyond the current model, and test its assumptions with different scenarios, and then see if those scenarios are worth planning for in advance (cost/benefit or any other perspective or priority you have).

Kotlin - Yet Another Language

What is the point? Yet another language on the JVM which has some syntactical sugar variance from everything else available. What for?

The next real programming language that changes something will do something that cannot be done in current languages. Python has its low barrier of entry and dynamic interpreting. Ruby has its textual flexibility so it is used as a DSL, and really showcased in Rails. Scalla has its static typing, with some flavor of functional programming. Functional programming in general is a different paradigm, and its flagship language is OCaml.

So what is the point of Kotlin? Just a slight twist on the same paradigms. Really not worth it. It didn't even do anything original with checked exceptions - it just got rid of them for the usual flimsy reasons.

The next language that will be significant will enable something that wasn't possible, or wasn't possible elegantly, previously. I suppose there may be space for a language designed so well that it eliminates pain points. Like IDEA used to be for IDEs. In truth, what bothers me most about the language is that it takes away resources from making IDEA truly great again.

Anyway, here are some things I would love to see in a new language:

1. Natural Database access, with static checking. So much business programing is done against the database, but lining those up (especially in the context of refactoring) is a major pain. Even Rails doesn't quite hit the sweet spot.

2. Natural XML access with static checking. When you do a lot of XML programming, it gets very hairy very fast. But the biggest problem is that it is a different language, essentially, with its own types and its own syntax, and you have nothing but string literals to deal with it in your programming language. How about variables that are XML types, loaded from the XSD (or a WSDL directly) by the compiler, and statically checked?

In the HTML world, you kind of have PHP for this, but it has problems, enough to justify a new language.

We spend way to much time either building RAD environments that are inadequate or creating glue code for no reason other than keeping a language general purpose. Solving this problem is what will make the next great language.

Friends don't let friends buy whole life

Why is whole life insurance a bad deal? Let me count the ways.

First, the fees are very high, so they may say things like "Guaranteed 6% return." Just ask if that is after fees.

Second, the cost of the term insurance is overpriced - it is basically a hidden fee. Quote term insurance separately at AccuQuote or SelectQuote or Zander (Zander doesn't even ask who you are) and see. Then consider the difference a hidden fee.

Third, if you die before your savings exceed the face value of the insurance, they keep all the savings. Talk about a lousy term insurance deal.

Fourth, if you die after your savings exceed the face value of the insurance, you only get your savings - what happened to the term policy you continued to pay for out of your earnings? It was still in effect until you get too old to insure. So you are paying an insurance for the insurance company to make more money off of you.

So what if your friend sells life insurance, but you aren't sure what to do? So you ask another friend. But what if the seller of the life insurance is a mutual friend? Will you get an honest answer? Think about it.

So if you check a reference, sometimes a friend, someone you trust, will be less than candid, because he has a conflict of interest. Always keep your eyes open.