Actors as a new model of computing

I know, I have not posted for way too long. Honestly the news on multicore sort of dried up. It is like we slipped into a hype cycle black hole.

Anyhow, as I was recently laid off from the day job, I have some extra web surfing time. I found this video on the actor model of computation. For a little background, here is the Wikipedia on the Actor model.

Let me warn you, this is geek porn. Three very smart people talking very deeply about deep computer science. The guy quotes Dijkstra and says he is wrong.

I sat transfixed for 45 minutes. If anyone finds a link to the book he mentions, let me know. I could not find it on Amazon. The ideas all relate back to an event driven mulitprocessor system. The idea of actors takes it further, many of the concepts are familiar and related. It is even more interesting to find this was out there and published for a couple of decades. Nothing new in the world I guess. I need to research and understand the ideas around inconsistency they discuss towards the end of the video.

Some further research found a number of papers by Carl Hewitt. He mentions which has a paper.


Founder Institute Graduation and me.

I have graduated from the Founder Institute Summer 2011 Denver class. Making that statement is huge.

Honestly, I can say I have learned so much in 90 days. None of the learning has been easy. Some of it does not apply to me and my start-up today, but it will in the future.

The mentors were great. If anyone reading this is in FI, or thinking about applying, here is one piece of advice. Take advantage of the access to the mentors. These are people who have started multiple companies and are currently running start-ups.  Talk to them, ask them difficult and stupid questions. Everyone really wants to help and make every founder a success. Do to a busy life, kids, and a day job, I did not talk to the mentors enough. Finally I had to take some sick days to visit with them in person. It was worth the time and effort.

The effort on homework is not small. Again, do the work and you will get the benefits. The things I have learned apply to my day job, and to my start-up. I am now an educated founder. As a technical guy, learning about the business side was great. All the things that I worried about just because I did not understand have been resolved. I have at least been introduced to hiring, raising money, lawyers and more.  This type of education is better than an MBA. It is an education in the way these things work in the real world.

So, I have graduated. I am still recovering and catching up at home and work. In the next few weeks expect more posts on the blog for Cloud Firmware.

Founding a company

In a previous post I said I was accepted to The Founder Institute. If you are interested in founding a company, just read the site there is an amazing amount of information available for free.

The Summer Denver 2011 class is two weeks from graduation. I am still part of the class, and am a founder now.

I have incorporated “About Five Technologies”, a Delaware C corporation. As of today I am the sole stock holder and the entire board. That may change soon, as I am seeking a co-founder or partner.

The product I am working on is Cloud Firmware. If you are interested in the company’s progress or embedded software, please sign up with your email.

Smart-grid Security


My current day job is working on ZigBee devices integrating with smart-grid power meters. So I follow the industry. If you want to keep up with the news of the day put FreakLabs Open Source Wireless into your RSS reader. They aggregate the news of the day.

They linked to Smarter hackers lurk in smart-grid future a post about smart-grid security from Greenbang.  As a smart consumer, you and I both know the only way to sell security is by generating fear. We all buy virus protection because we fear our computer will get powned. We lock our doors at night because we fear a break in.

In the article they put up the straw man argument that a hacker could bypass multiple layers of security, understand unusual and proprietary wireless protocols, and then break into your house.  I have to say “WHAT!?!?!?”.

Stop using the intruder argument for security. A sophisticated hacker decrypts RSA keys, then uses a crow bar to break down the door? Really? No, I mean really? How about  just watch the house and see when you drive away. That seems easier than running a network sniffer and decoding keys.

To be fare, the article uses the intruder as an example, then warns that there a bigger security issues. Major things like mass power outages and Stuxnet viruses should be the focus of security.  The “your not home so someone will break in” example over simplifies the issues and needs to stop. Please, please if you found this in your search to write a network security article do not imply that someone may break into my house because of my smart meter.

A better hack

This was in the back of my head while out walking yesterday. I thought, “if you could hack the network, what would you really know?” How often I run the dishwasher? BFD. That led me to a much better hack.

Please, do not come and arrest me for posting this. My point is not to enable crime, just to point out the folly of security theater. Schneier on Security is my role model here.

OK, so lets pretend we are real sophisticated crackers. We want to make money from the smart-grid role outs in our town. So we start hacking the utility systems. That seems hard and as a cracker, I am mostly lazy.

Instead, let’s send out some spam. Spam is easy. The spam says (I am paraphrasing here.):

I am the evil smart meter cracker that the utility warned you about. Do as I say or I will mess with your meter, cause a power outage and give you a giant electricity bill!

Pay me $5 per month and I will change your meter settings to save you $20 per month. The utility is just trying to screw everyone, so lets stick to the man. For $10 I will save you $30. More than that is dangerous and we may get caught. Don’t tell anyone, see above.

Send payment to my overseas criminal account (or use bitcoins) details here.


Smart Grid Cracker

Now, here is the beauty of it, don’t change a thing on the meter or smart grid. If the cracker actually has access, then they can send monthly emails saying “You bill is for X it was X+$20 before I changed it, we are sticking to the man!!”. This scam can work with absolutely no network access, just a spam email system.

Now, please tell me how much encryption to use inside the network to fix this huge security hole?


(Editors note. I wrote a series of rants on requirements in a blog a friend and I were working on. It was called “Doug and Doug doing Embedded Design”. We have since taken it down mostly due to a total lack of interest from us and zero traffic. We did it to support a side project building a car mp3 system.

I am putting the rants here, because they are part of my development manifesto. I also need some easy posts as I am really busy for the next few weeks. I have edited the posts and tried to test links. If you see any issues, let me know.)

Building the product requirements

If we are treating this project like a product development effort, where do we begin? The answer in most companies is with the Marketing Requirements Document. Every engineer reading that last sentence just let out a groan of agony.
Don’t get me wrong, as an engineer I think marketing is hugely important. I have worked closely with some very good marketing people. If the marketing people you work with do not know all about this, you have bigger problems than just requirements.
But wait, Joel says we need a document. It is one of the 12 items in the Joel Test.
I can hear your argument being shouted back, “wait you fools! The 37Signals guys say don’t do it”
The truth, as usual is not black and white. Personally I lean towards Joel Spolsky’s way of thinking. You need some way to communicate what you are planning to build to everyone involved.
In the 37Signals case, there are few people involved. They do mock ups and design the UI of their applications before coding begins. That could be called the requirements, but they would object to the word.

In my experience the requirements process is always a failure. I have read and researched the topic. It seems to me that it should be very a useful and good thing to know what I am building before I start. As an engineer, I crave a detailed and complete requirements document. I am always been left hungry.
Why does Marketing get to decide anyhow? We are the engineers. We know what to build! We built the widgets that paid for the building they sit in. For anyone curious about the history, there was an article in the Harvard Business review titled “Marketing is Everything” by Regis McKenna from 1991. A book followed. If you read the article it describes the coming utopia of market driven companies and happy empowered consumers.
Alas, the practice is much harder than the theory.

Requirements are really hard

A recurring them on this blog and I have found in life is the fractal nature of reality. Requirements sound simple, write a document that says what to build. Requirements are an art and science in their own right. As we zoom in, the details are complex at any level.
There is a requirements convention and an IEEE society, plus many books.
Two of the best I have read are Exploring Requirements: Quality Before Design by Donald C. Gause, Gerald M. Weinberg  and Customer-centered products : creating successful products through smart requirements management / Ivy F. Hooks & Kristin A. Farry.
Anything by Gerald Weinberg  is usually worthwhile.

Why the requirements process fails

Here are some of the ways I have seen the requirements process fail. Doug and I will try to avoid these pitfalls in our simple requirements.

Marketing is not able

In the beginning, the founders get together around a great idea. There are few people around the lunch table. They throw out ideas and one is really good. It gets hashed out and everyone understands. They found a company and build the idea into a business.
Now after a while, it is time to build a new product. This will be a really new product, not an add on or update to the original. Of course, the founders sold out or left last summer to spend their dump truck of money they earned off the first idea.
The marketing people are now tasked with writing the requirements. Of course, they have never done anything like this before and no one on staff is a requirements expert. No one has read the books, so the time needed is underestimated. Read that last sentence again, it is the killer point.
Marketing is out trying to setup a time to talk to customers, get an NDA in place before they do, and not piss off the sales people. Because this takes much longer than expected, the engineers who were sitting in on the kickoff meeting get bored. Bored engineers are dangerous, idle hands and all that.

The Engineers know what to build

As engineers, we are industrious by nature. We go and gather our tools and begin to build something. Depending on how long the marketing group takes, we may be pretty far along.
When the document is delivered, deliberated at the highest levels in the organization, and passed down to the engineers the conversation goes something like this:
Engineer: :”We can’t do that”
Marketeer: “Why not?”
Engineer: “We never planned on that feature in the design.”
Marketeer: “Why are you planning and designing without the requriements?”
Engineer: “You took to long, it is always up to us to make up the schedule time, etc.?”
Marketeer: “What did you build?”
Engineer: “The same thing as last time, but we put a clock in it.”
Marketeer: “Arrrrggggg!!!!” Slam (Conference room door slamming and the sound of fading screams in the hall).

Sales is in the drivers seat, not marketing

This is the classic. The sales team does not want anyone grilling the customer about what comes next. If the customers know a newer, bigger and better product is around the corner, they will wait and not clear the old product off the shelf.
So, a smart sales persons says, “I talk to customers all the time, I know what they need, just ask me and we will get these requirements done quick!”. This is the sales person as proxy for the customer syndrome. As an engineer I have to say it is one of the worst syndromes a company can have.
Marketing talks to sales. Sales wants feature X. Feature X is big, ugly and difficult. A fearless engineer, lets call him “Doug” asks, “Why do you need feature X”. It goes back and back through layers and up and down the hierarchy. Finally the answer returns and it is always the same, “Customer A said they would buy $1 bazillion worth if we had feature X.” OK, now Doug asks “How much will they pay for feature X?” The answer, “Pay? no, they won’t pay extra for it.”
This time it is the engineer running through the halls with his underwear on his head screaming.

The customer says ‘whatever’

Once again the company goes out looking for feedback from the customers. When the customer finds out this is not even a real product yet, could get booted at any time, and will not be in their hands for over a year, they just don’t care.
Very few customers have time to tell you what you should be building. Usually they are busy running their own business. Yes, the product may be revolutionary and really save them money and make life easy. The fact that you still have to build it and they must wait is a complete turn off.
Even worse, if the customer realizes they have a need that your current product does not meet, maybe a competitor’s does. Or why buy now? Why not wait for version 2.0?
Most users don’t know what is possible. So it is very difficult for them to have an opinion about the next generation of your product. Most of the feedback is either completely impossible, costs way to much, or goes like this, “Just build the same thing as last time, but put a clock in it.”

Exactly how many customers responded to the survey?

Be very careful when you hear statements like “All the customers need this feature”, or “everyone we spoke to has to have it or they will not buy”.
The flip side of customer apathy is the over interested customer. If most people can not be bothered, there will be one who is more than willing to specify a product that meets their exact needs. Does it meet the needs of a larger market? Well, that is our problem, not theirs.
In more than one company on more than one occasion I have found that “all customers” really meant the one who we met. You can not do statistics with only one data point. Two is not much better. Unless you are selling to the government, there had better be more than a few customer contacts.

Requirements are just hard to get right

Most small and even large companies do not have a requirements expert. I have never actually encountered someone who has read the books I recommended above. Few companies will go to the expense of hiring a consultant, at least not at the beginning.
Most of us muddle through using one of the three methods listed above. Some poor soul is given the task of writing the actual document. It is unfortunate that the result is usually a document. A database or tool could really help.
The document is written in good faith as best as can be managed. It gets sent off to the engineers and immediately rejected. Meetings are scheduled and time is wasted going back and forth repeatedly. In the end, we build the same thing as last time, but put a clock in it. Sigh.
What went wrong? The engineers complain that the document was:

  1. not specific enough
  2. told us how to implement features, not what they were
  3. gave no priorities
  4. was too detailed
  5. had untestable requirements

In the back and forth some important things get dropped, the wrong ones get emphasized and it winds up being design by committee. A generic product is described that looks just like everything else in the market.
If no resolution can be found in the meetings, the project is thrown into development with orders to “just do it”. Maybe a consultant gets hired to sort it all out. See the section about bored engineers to see how this works out.
Rinse and repeat.

Parts two and three coming soon.

Asynchronous Communication

I just rediscovered this post from Oreilly about asynchronous communications. Take a moment to read, I will wait.

It brought to mind another recent article about how multicore programmers must think differently.  The author is arguing that “different” thinking is needed, not that multicore is harder than regular programming.

What relates these two things? Asynchronous communication is multicore.

People attracted to programming are by nature and by training linear thinkers. Step on leads to step two and three, so on to the end. Sequential programs are drummed into our heads through all our college years.

Unfortunately, I am not a linear thinker. I am a leaper. Step one leads to B which jumps to crocodiles, and that means the answer is 7, done. Being a leaper in a linear world is a double curse. It is hard to communicate with the linear thinkers, because either I have skipped three steps and already arrived at my answer, or I do not follow their steps, so can not see the big picture without more detail. Plus, as a programmer, taking to the non-technical is always a bit iffy.

Understanding that the world may not happen step by step is the first step to understanding multicore. Process A may finish before B, sometimes, but not always. The messages may get swapped in transit. We can put things back in order, or find a way that order does not matter.

It is an asynchronous world, and linear thinkers better get used to it.