The Hiltmon

On walkabout in life and technology

Explaining the Internet to Old Powerbrokers

Ben Hammersley gave a speech to the IAAC and reproduced it online at Check Against Delivery. My speech to the IAAC. Instapaper it and read the whole thing, it’s one of the best things I have read in a while.

In short, he explains the importance of the internet to a bunch of old, pre-internet security politicians. He points out how their ignorance is viewed by the rest of us, and how their decisions, while correct by their lights, are completely wrong and insipid.

Some gems:

My theme that day was that the world is currently run by a generation whose upbringing has left them intellectually unable to be deal with modernity.

You’re all the same age, and upbringing, as the people that the digital generations are so upset with.

We can bitch about it, but Facebook, Twitter, Google and all the rest are, in many ways the very definition of modern life in the democratic west. For many, a functioning internet with freedom of speech, and a good connection to the social networks of our choice is a sign not just of modernity, but of civilization itself.

What’s worse, is that the phrase “security precautions” has become a synonym for “pointless annoying thing to do because politicians are either stupid or oppressive”.

Spike Solutions

I am a huge fan of throwing together a few spike solutions at the start of a project. I get the biggest technical problems solved early, I gain understanding of any pitfalls I may encounter and I can estimate the time and work better. I highly recommend the practice. A few days spent spiking solutions saves weeks and months later.

Get your geek on, were diving in.

A spike solution is a software project to figure out a tough technical or design problem (note: singular). Use it to explore potential solutions, ignoring all other requirements and standards. Expect to throw it away. The goal is to see if and how a specific problem can be dealt with.

I use spike solutions in several scenarios:

  • To see if something is doable
  • To help me understand the issues relating to a technical problem and to find pitfalls
  • To help create better estimates for large and complex projects
  • To see if I can make something faster or more reliable

I have an itch to scratch, a product that I’d like to have and therefore to write. Sorry, not saying what it is. So I start thinking about the feature set and the technical needs.

To paraphrase Donald Rumsfeld, there are known-knowns, known-unknowns and unknown-unknowns. Nothing you can do about the unknown-unknowns. You already have the known-knowns covered. It’s the known-unknowns that concern me. So I spike them.

In this case, I have three known-unknowns in the projected application - how hard is OAuth2, can I create some of the display widgets and can I thread plugins. Looks like I have three spikes to work on. We’ll look at the first.

Example: SpikeOAuth2

If you want to see this spike solution, it’s available at hiltmon / SpikeOAuth on GitHub. Warning: It’s a spike solution, so no documentation, tests, coding standards or refactoring. In other words, this code stinks, do not use it.

First, I looked at the protocol at OAuth 2.0. Ouch, looks complex. Will take a while to write. But it seems like that’s been taken care of as they link to existing code libraries. This may be easier than I think. But I am a little concerned. The application will rely on a robust OAuth2 implementation, are these good enough? And neither of these are both Mac and iOS, which is what I need. Still worth spiking.

I did a bit of research and came up with a library that seems to fit the bill. Oauth2 - check, Mac version - check, iOS version - check, reputable maker - check. It’s Google’s gtm-oauth2 library. So, can I make this work?

I created the spike solution. Figured out the dependencies. Got it compiling. And it failed to work first time on the first site - StackExchange. Ok, into the debugger, added log statements to the Google code to see what is going on. And lo and behold, a bug on the server side was causing it. A quick turnaround with support (see Receiving “redirect_uri does not match the uri used to create the passed code”, when it does match) and it works. Kinda. The Google library, it seems, is too new, and StackExchange does not yet support it. Pitfall found. Quick hack to the library, and it all works. This spike, and this library, seems promising.

But can it access other sites just as reliably?

Try another site, Disqus. Wow, that went smoothly. Ok, try Google, using the standard version of the library. Yay, that works. I now have confidence in the library.

Just one more test - Twitter.

Bah-booooww.

Twitter does not support OAuth2. Research shows that several of the sites I want to access are the same. And OAuth2 is not backwards compatible with OAuth1. New issue identified, pitfall encountered. Now what?

Since Google has an OAuth2 library, I checked to see if they have an OAuth1 library. And they do. Added it to the spike, handled the conflicts. And now the spike does OAuth with Twitter ok.

The spike solution has proven that I can do OAuth (1 and 2) reliably with Google’s code. One known-unknown is now a known-known. Time to walk away and get on to the next spike.

Next Steps

Now that I know that the OAuth2 process is doable, there is much that could be done to this code to make it better and more usable:

  • Instead of one View per source, create a single View and create an object for each source as a parameter to the view
  • Consolidate the common code into a common object, and enable each source to configure the common object instead of repeating all the authentication code
  • I am unhappy that the OAuth and OAuth2 code libraries are separate, with much repeated code. I plan to create a forked version of the Google code such that the user just chooses which version of the protocol to use and the library will handle it. Should get rid of the duplicated authentication and signin objects. And I could probably share it for others to use.

But I’m not going to do any of that now. The purpose of this spike solution was to see if using OAuth2 was doable, and how hard it was. Now I know. It has done its job, proven that it can be done and how to do it. I know how much work and effort it will take to add connections. When I get to writing the real application, that’s when I can and will do the rest.

Now on to the next spike.

Adjusting the Cap

Alex Knight, writing in his own blog Zero Distraction in The Disparity between Smartphones And Mobile Carriers sets the scene exactly as I see it:

There’s a massive disparity between data sucking smartphones and data plans offered by carriers. Customers know this, and the carriers are fully cognizant of it. The problem is they make a ton of money from you already, and since you probably don’t have a lot of choice as far as competition is concerned, they can charge whatever they see fit.

Then, in my opinion, he gets too optimistic:

The larger, and perhaps more onerous question is this: when will carriers come around and open up their data caps to a reasonable degree? I’m not one to argue that carriers need offer truly unlimited data plans, however, I posit that if they were to offer dramatically higher monthly caps, they might be able to attract new customers — not to mention keep existing ones happier, all whilst charging them a more reasonable rate.

I humbly disagree and this is why.

The utter lack of competition on the US mobile market means that all mobile providers generally offer the same ridiculous plans, even for fast LTE coverage. They are not willing to start a price-war with each other, because they are all making mountains of cash where they are.

The second issue is that the average mobile user is locked into a 2-year plan, and has to burn hundreds of dollars in penalty fees if they try to exit it. So even if the price-war happens, if another carrier does decide to raise their cap or offer a better deal, only the few smartphone users who are at the end of their contracts can take advantage of the offer.

Thirdly, carriers change their plans and caps regularly. The subscriber contract and massive ‘donations’ to the FCC ensure that consumers have no say when this happens, they are forcibly moved to the new plan. Since the carriers have traditionally raised prices, changed contract terms and lowered caps (or added them in the case of unlimited plans), consumers do not trust what they say or advertise. If another carrier offers a better deal, and a consumer signs up, what’s to say that that carrier will keep the deal. It’s not in the carrier’s interest to do so as the new consumer is now locked in for 2 years. In short, consumers do not trust the carriers at their word, and carriers keep changing the game.

Finally, when it comes to consumer satisfaction, the carriers don’t give a hoot. Every year they rank at the bottom of customer satisfaction surveys, and have done nothing so far to change this. They are not in the business of selling satisfaction, they are in the business to make money. They have a huge number of locked in customers (no need to spend a penny making them happier), and the percentage that can leave, have nowhere to go, so they stay. No need to spend a penny trying to hold on to them either.

I believe that the carriers will maintain their caps as long as they can in order to generate more mountains of cash. They have no incentive to do otherwise. And I don’t expect the consumer or the government to have the ability to change this in the near future.

And This Is Why

Life, communication, programming, it’s all about structuring a rational argument. But too many people are either unable to, or are unwilling to, rationalize.

“I hold this opinion because I’ve read the facts and thought it through” matters. “I hold this opinion, and that’s it” doesn’t.

Whether the argument is about creative design, system architecture, which restaurant to eat at or politics and religion, it’s critically important to express, clarify and declare the rationalization behind it. Failure to do so, or the inability to do so, changes the argument from a rational, reasonable one, to a waste of time, words, and emotions. Unfortunately, rational discourse has given way to spin, faith, linguistic traps, talking points, lies and misrepresentations that are treated with the respect they do not deserve.

Having taught people who think “it’s my opinion and you can’t tell me I’m wrong” I see how important the skills of rational argument are.

The only way to beat irrational discourse is not to partake in it, and to avoid people who do. It’s not easy, and sometimes not possible, but an irrationally held belief or opinion will not be swayed by rational facts, and I don’t know why. Maybe its laziness, maybe its a comfort factor, maybe it conformity, maybe it’s to avoid being embarrassed or being perceived as wrong, maybe its just plain stupidity, I do not know.

Whenever I express an opinion, I always complete the sentence with “and this is why”. It’s a habit I got into years ago, taught to me by a friend I worked with. He is a very intelligent and persuasive person, and the secret to his persuasiveness is his ability to express an opinion and then explain why – clearly, unambiguously and with factual support. I’m not saying he was never wrong, he was. But when presented with a rational counter, he was smart enough to listen, absorb, understand the counter, and change his position to the one the facts and rational argument led him to. And when faced with an irrational counter, he walked away.

One of the big problems with Twitter is that 140 characters is not enough space to add the “and this is why” part to a tweeted opinion. One of the big problems with Hacker News, Reddit and the Disqus forums I use, is that most commenters do not include an “and this is why” component to their responses. The 30 second sound byte on the news has no time for an “and this is why”. I don’t know why we accept this kind of behavior, it’s become the new norm, and it’s wrong. Why? It’s too easy to express an opinion, it’s much harder to think one through, explain it and defend it.

One of the reasons I prefer both reading and writing long form blog posts is because these usually have the “and this is why” component. They open my mind up to new ideas, they help me understand my own opinions, they help me find the positions that I should take because the facts presented lead me there. I seek those discussions that support my opinions, and I seek, with the same determination, those that oppose my opinions. But I only spend the time to absorb those supported by clear, supported, facts. I can only rationalize, express and argue my opinions if I understand both the pro and con positions. And, of course, I choose the opinion where there are facts on one side, and none on the other.

And maybe that’s what this is all really about. Opinions are a choice, we choose them. We can be lazy and just follow the crowd, sharing other people’s opinions without trying to understand the choice or the opinion, and slavishly repeat their mantras. Or we can take the time to study the facts, learn the truth, understand the consequences and choose the right opinion to support and express.

So next time you express an opinion, add “and this is why”. Try it. Then continue on to explain why you hold the expressed opinion. It won’t be easy, but it will teach you how to structure a rational argument. It will teach you how to think through, understand and solve problems. It will teach you to think about your choices of opinions. And make you a better communicator, programmer and person.


This post was triggered when I randomly saw the two quoted tweets by Ian Betteridge. He wrote them in a different context, this is how I perceived them in my context.

I Love Debugging

Rob Galankis tongue-in-cheek writing in Why I hate Test Driven Development:

… So why do I hate TDD?

Because debugging is fun. There, I said it. I love debugging. I think lots of clever people like debugging. I love someone having a problem, coming to me, looking at it together, getting up to walk around, look at the ceiling, talk to myself, stand in front of a whiteboard, draw some lines that spark some idea, try it, manually test a fix out, slouch down in my chair staring at my computer lost in thought, and repeating this until I actually find and fix the problem.

I don’t mind debugging when there is no deadline. I love TDD when there is.

Photoshop Etiquette for Web Designers

There is a brilliant list of things web designers should be doing when desiging web apps in PhotoShop at the photoshop etiquette manifesto for web designers. Do these and we developers will have a much easier time implementing your designs.

Applies to iOS app designers, Mac App designers, in fact any app designers too.

From now on, all my designers will be asked to follow these rules.

Maker’s Schedule, Manager’s Schedule

Classic article by Paul Graham in 2009 called Maker’s Schedule, Manager’s Schedule.

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting.

One of the reasons I went indie is to stay on my own maker’s schedule.

The Mac App Store Needs Paid Upgrades

Brilliant post by Wil Shipley on his blog called The Mac App Store Needs Paid Upgrades, well worth a read:

Right now developers selling through the Mac App Store face a lose/lose choice: either provide all major upgrades to existing customers for free (thus losing a quarter of our revenue), or create a “new” product for each major version (creating customer confusion) and charge existing customers full price again (creating customer anger).

Here’s hoping Apple is listening.

On Digital Hoarding

Melinda Beck writing in the WSJ in Drowning in Email, Photos, Files? Hoarding Goes Digital presents a fact-less and ridiculous claim that we are doing something wrong by storing all the emails and files that we do. In the article, she equates the rest of us, people and companies alike, with those crazy nutters who fill their houses with junk.

My take: We, especially businesses, need to keep all old emails under law in case of subpoena, just like individuals need to store tax records. We need all our old work files as they are referenced in later works. We need our music and photo files because we no longer have their physical equivalents (or have to buy them again and again in case of media). In short, we’re not hoarding, we’re filing, scrapbooking and holding on to our possessions that are no longer physical.

But let me respond to the article.

You’re Being Stalked

In the same vein as an earlier article on my blog, Giving Yourself Away With a Facebook Login, Alexis Madrigal writing in the atlantic in I’m Being Followed: How Google—and 104 Other Companies—Are Tracking Me on the Web quotes Joe Turow saying:

If a company can follow your behavior in the digital environment – an environment that potentially includes your mobile phone and television set – its claim that you are “anonymous” is meaningless. That is particularly true when firms intermittently add off-line information such as shopping patterns and the value of your house to their online data and then simply strip the name and address to make it “anonymous.” It matters little if your name is John Smith, Yesh Mispar, or 3211466. The persistence of information about you will lead firms to act based on what they know, share, and care about you, whether you know it is happening or not.

She refers to the WSJ investigation called the Web’s Cutting Edge, Anonymity in Name Only, also worth reading.