The main point of going to New York for the Web 2.0 Expo was to participate in the Startup Showcase. It was described as “the speed dating version of your pitch” because about 30 companies would be set up at small tables in a large room and people would circulate and every five minutes a bell would ring and everyone would go to the next table. This would continue for about 90 minutes after which the two judges (Tim O’Reilly and Fred Wilson) would each pick a company and one would be voted in by the crowd. Those companies would be invited on stage to have a conversation with Fred & Tim.
Mary Haskett and Dr. Alex Kilpatrick prepare to pitch
The point, from my perspective, was to practice and refine our pitch and to get more feedback. My appetite for feedback is voracious. I want to hear from people who like our idea but I especially want to hear from people who do not like it. I want to know why. So I expected to make it to the stage – because we are awesome – but it wasn’t really important to me. Talking for an hour an half to a whole bunch of people was an end in itself.
So the set up was about how I imagined, except the large room had two bars and waiters circulating with trays of hors d’oeuvres. And the whole speed dating thing went out the window as soon as we started – it was just a swarm of people in a loud room pressing close and listening. They came and went randomly and soon Alex and I were both doing two pitches simultaneously on each side of the table. Most of our planning and preparation went out the window but it was fun. I was close to losing my voice.
We didn’t make it to the stage, but both judges said nice things about us. If you listen, it seems like Fred is about to tell the crowd why he didn’t pick us, so I’m going to have to follow up with him and see if I can find that one out.
The Ignite! event in New York was held in conjunction with the Web 2.0 Expo and it was a fun and well run event. I love the format – 5 minutes to speak on any topic, 20 slides and the slides advance automatically every 15 seconds. It’s challenging to stay on pace and you really have to hone your topic down to the pure essence to get in to fit.
Alex’s topic was “Defeating Big Brother – How To Fool Biometric Sensors”
Here is Alex’s presentation:
Nora Herting of ImageThink joined the Ignite NYC team to document last night’s Ignite NYC X: Web 2.0 Expo Edition. Here is her rendition of Alex’s speech
WanderID has reached what we consider the minimum viable product status (see: Lean Startup) and so it’s time to reveal our new creation to the world and get feedback from actual customers. As part of this, we are beginning our efforts to spread the word.
We are going to New York for Web 2.0 Expo and participating in their startup showcase. I love the format – it’s like speed dating for new companies. For 50 minutes we do our pitch for the crowd. They ring a chime every 5 minutes and we start over while our audience goes to the next company. The conference looks great so if you are in New York on September 27th, come by and find me. Give me good feedback on WanderID and I’ll buy you a drink.
Alex submitted a proposal for Ignite NYC X and he got accepted! His topic is “Defeating Big Brother: How to Fool Biometric Sensors”. Alex is not afraid to take on controversial topics. That one is going to be a lot of fun.
WanderID was mentioned in an article about ID products for special needs children:
“Child ID options for special needs children include identification bracelets, temporary tattoos, tracking bracelets and biometric face matching technology.”
Today my family and I were taking our open water tests to be certified as scuba divers. I had bought the family wrist-mounted dive computers because I saw them as cheap insurance, and because I got a good deal on them. A dive computer measures your accumulated nitrogen, so you can be sure you don’t stay down too long. One of the instructors for the course noticed the computers and asked me if the shop gave me a good deal on them as a package. I said “Oh, I didn’t buy them in the shop, I bought them online.”
Big awkward pause.
He then commented “I don’t like to hear that. I hope you don’t ever get in a position where you have to get air fills online. I guess you would have to hook up your USB port to your tank. Ha ha.”
I also got grief from wearing a scuba.com cap. The veiled threat here, of course, is that by shopping online I will put the local dive shops out of business. Once they go out of business I will no longer be able to fill my tank because that is one thing you can’t do online.
In a word: Bullshit. This kind of argument has been made for ages. I’m sure Oog the caveman made the argument that the other cave people should not buy the new round wheels from Grog. I have never bought the argument that you have some kind of guilt-based obligation to shop at one place over another place. It isn’t my job to make sure the dive shop is going to be open for the next ten years, or the next year, or even the next week. It is the dive shop’s job to make sure they are offering services and goods that people want. If they do that, they will be successful.
Loyalty is not something that can be earned by guilt. If I had a friend who ran a dive shop, then I would certainly patronize it because I have loyalty to my friend. If I build up a long-term relationship with the owner of a shop, then I might end up having the same loyalty. Or maybe I will have a social group that is tied to the shop. There are lots of possibilities. However, the fact that I have taken a class at a shop, or that fact that the shop is a local shop is not in any way something that can generate loyalty.
The dive shop is a microcosm of a lot of brick and mortar shops who are faced with internet competition. They seem to be fundamentally unable to innovate. As a classic example, look at Zappos. Who would have imagined that you could put something like a shoe store online? That seems like the ultimate brick and mortar store because you can’t try on shoes online. However, Zappos figured out that they could offer more information, better prices, and an incredibly liberal return policy. That allowed people to shop without risk. The online scuba scores have copied the same approach, allowing you free returns in order to ensure you get something that fits well. They also provide a wealth more information on products, lots of reviews, better prices, and a greater selection. In short, they have figured out how to compete in a new world.
In all fairness, I did ask about computers at my local dive shop. The computer I was interested in was twice as expensive as it was online. I asked the owner “Can you tell me what the real difference is between the different model of computers?” He said “Well, I really don’t know much about the computers. I have been diving for thirty years, and I don’t use them.” Ok, then. We have something that is twice the price, with less information. And I am supposed to be loyal to my local dive shop?
How can the dive shops compete? By thinking outside the box. Here are just a few ideas, and I have hardly spent any time thinking about it:
Allow customers to try out gear. Currently, most dive shops rent really crap gear. They could rent high-end gear at a more expensive price to allow people to try it out for a few dives before buying it. Credit the rental fee to the price if they buy.
Sell “certified” used gear. Currently, there is a big risk to buying gear from someone on eBay or Craigslist because you have no idea if it is good, or current. The dive shop could sell used gear on commission, and certify that it is fully operational and not obsolete.
Arrange “try out” events where people can try exotic equipment (like rebreathers) or high-end equipment in the dive shop pool
Focus more on classes. The class I went to was too crowded. I would have paid more for a smaller class and more personal attention
Focus more on building a local social dive community. Most shops don’t seem to do this. (I don’t know why)
Maybe none of these will work. Maybe the ultimate end result is that local dive shops will go out of business and there will only be a few specialty shops doing air fills. Or maybe Wal Mart will start doing air fills.
Ultimately, the consumers and the market will decide, based upon what is the best value. I have no idea how it will wind up. I just know that guilt is never going to be the solution.
In 1984, when both Eddie Murphy and Dudley Moore were near the height of their popularity, they made a movie together called Best Defense. Amazingly enough, even though they were co-stars in the movie, they do not share any scenes. This was, by all accounts a mediocre movie – IMDB has is rated at 3.2/10. But it has a lot to say about the life of an engineer.
I remember seeing this movie in high school, and thinking it was pretty mediocre at the time. However, a couple of elements of the movie have stayed with me. There are spoilers ahead, so if you are worried about spoiling this 26-year-old movie, you should stop reading now. Also note that I have not seen this movie since it was at the theater, so I may have revised it in my head over the last 20 years, changing the plot somewhat to better suit my worldview.
The plot centers around Wylie Cooper (Moore) who is an engineer working for a defense contractor, and Lt T.M. Landry (Murphy) who is in the Army in the Middle East (how prophetic). The twist is that Wylie and T.M. are separated by two years, and never actually meet. Wylie is working on the tank that T.M. will be driving two years later. The plot jumps back and forth between the two characters/timelines. In the “engineer” timeline, Wylie is arguing with his bosses about a particular part of the tank that might overheat in the right situation. In typical Hollywood contractor fashion, the company does not want to spend any more money on the tank design. They go back and forth and eventually Wylie wins out and incorporates a fix into the design to deal with the overheating. The “Army” timeline is more tedious and slapstick, with T.M. blundering around in the desert, eventually stumbling across a border and having to engage a real enemy. That special part on his tank overheats. Wylie’s fix saves the day, and everything works out in the end.
The thing that is interesting to me about this movie from a software perspective is that it very graphically shows the disconnect between the developer and the end user. In the movie, the engineer knew what was the right thing to do, and he stuck to his guns. The Army guy was saved by an engineer he would never meet, based upon a debate he never saw, using a fix he wasn’t aware of, and in a situation he could never have anticipated.
Engineers don’t often talk about a code of ethics the way doctors talk about the Hippocratic oath. However, this kind of example really crystallizes the core duty of the engineer. You can talk about methodologies all day long, but ultimately your responsibility it to the end user of your system. Ultimately, that is all that counts. You can have beautiful code, a gajillion tests, using the latest injection frameworks and documented from here to Sunday. But if the system is not reliable, or does not solve the problem, then you have failed. You can’t make software that works in all situations, but if your software breaks on small branches from the garden path, then you have failed. If you don’t anticipate unusual things that your users will do and make your software handle them, then you have failed. All the good intentions leading up to that point don’t really matter. Your software has to work.
And know that if you do everything right, you will save some end user from some situation varying from a minor annoyance to life-threatening. And they will never know you or know what you did, or even know that anything special happened. Being happy with that kind of implicit gratitude is what makes an engineer.
I was at a conference recently, talking to a woman about our product. The woman was the security manager for a large organization. I had mentioned that we run our servers in the cloud, so we can easily scale, etc. etc. She commented something like “Oh, I would never be comfortable having my information in the cloud” I had heard this sentiment before, but never talked to anyone who felt this way, so I asked her why. She commented that she would be worried about having the information out of her control, and mixed in with all the other applications in the cloud.
I actually believe this is an artifact of the terms we technical people use for things. “Cloud” has been used for a long term, certainly predating cloud-computing by decades. In the jargon sense, “cloud” means “something that has some characteristics, but you don’t need to worry about how it works inside.” The internet itself was always portrayed as a cloud. You send a message into the internet cloud and it comes out the other side at a destination. You don’t care what happens in that cloud. By that meaning, the regular mail system is a cloud. But so are a myriad of other things: my car: I just push buttons and it goes; the supermarket: food just shows up there somehow; laundry: I drop my dirty clothes on the floor and they show up clean in my drawer.
The important thing to realize is that everyday you deal mostly with clouds. You can’t possibly understand the details of more than a few things in your life. And cloud computing is no different, except that most IT people are used to seeing racks of physical servers humming in their little air-conditioned havens. It is disconcerting to think of moving from a paradigm where you can touch all your assets to one where your assets are in some nebulous cloud somewhere.
But let’s examine the security issue by breaking it down into two attack vectors: internal and external. In terms of an external attack, there is little difference. If I have outdated patches, poor security design, etc., my physical server is just as vulnerable as my cloud server. However, my cloud provider may have more intrusion detection/prevention mechanisms than I can muster. Internal attacks are different. It is much easier to get into a server if you have physical access to it, because you can boot the machine from an external source and access the hard drive (assuming it is unencrypted). If you have physical servers, are they locked? How secure is the room? Do you ever have disgruntled employees? I think you see where I am going here.
Getting into a virtual server at a physical data center where cloud instances are hosted is a much more complex proposition. First, you have to get physical access to a highly secure data center. Second, you have to know which machine a virtual instance is hosted on. Third, you have to get physical access to that machine. Fourth, I don’t know. I don’t even know what it means to get physical access to a virtual server. It is probably a moot consideration since you can’t boot a virtual machine separate from some host. But having physical access to the machine that is hosting the virtual machine means nothing if you don’t have the credentials to get onto the virtual machine. Of course, the majority of data breaches come from external sources anyway.
OK, but doesn’t the cloud provider have secret backdoor access to all their servers? Amazon EC2 uses a public/private key pair to generate the initial password for your virtual server. (not sure how the other ones do it) You have the private key; they don’t. That means that they cannot get into you server, no matter how hard they might want to. There is a non-zero probability that they have some special version of Windows Server/Linux that has a secret backdoor password, but that is definitely in tinfoil hat territory. Of course, they have every incentive to make things as secure and private as they can. If they screw it up, they can lose tens of millions of dollars in business. Does your small IT staff have the same incentives?
Analogies are dangerous, especially in computing. They are always a simplification of a more complex situation. Sometimes they make us less cautious than we should be, like when people think of a cell phone as the same thing as a wired phone instead of a radio that transmits. However, I believe the cloud computing is one of the cases where our analogies make us overly cautious. We put too much stock in the security of the physical thing we can touch as opposed to the abstract concept somewhere else.
One of my Facebook friends (my first girlfriend, interestingly enough) is working on a degree in computer forensics, and occasionally sends me questions from her class. I guess the professor wants the students to talk to someone who is in the information technology career field. The most recent question was:
Why do companies often release software that is not bug free?
The format of the question made me chuckle. The “often” part presupposes that sometimes companies release software that is bug free. But that is patently ridiculous. For programs of even a small level of complexity, it is impossible for them to be 100% bug free. And by small level of complexity, I mean more than a few hundred lines of code. Here’s why it is impossible: first, the number of execution paths through any program is so large that you can’t test them all. Period. It isn’t just whining when we say we can’t test all the execution paths. It is just math. Let’s look at a real-world example from some code I am working on now.
This is the simplest function I could find, part of the data layer. Don’t worry if it doesn’t make sense to you. In English, this function basically says “Get me the data about a person with a certain ID number from the database.” However, just this simple operation is involving five different function calls, and four different separate components. There are thousands of lines of code executed behind the scenes just to make this function work, and lots and lots of branches as that code is executing. Just to give you an idea, this function goes through the following layers (more or less):
My code
Lightspeed data access layer
C# LINQ runtime
C# CLR
MySQL C++ DLL library
MySQL C++ code
File system (through OS)
Microcode
CPU
And this function itself has 2^32 possible inputs! Additionally, this function is at the bottom level of a bunch of complex code in my program. It would be impossible to test all the possible ways this code can execute, much less the more complex code on top of it. So, the idea of “bug free” is a myth.
However, I do want to be helpful, so I am going to rephrase her original question:
Why do companies often release software with obvious bugs?
Short answer: laziness. Slightly longer answer: time is money.
Looking at the code I pasted, I noticed it does have a potential bug. I don’t check to see if the id is in the database. If the id is not in the database, then this function will crash in an uncontrolled manner. I asked myself why I am not doing such an obvious thing. And the answer is that I have a pretty deep understanding of my code, and I happen to know that this function will only be called by functions that have a valid person ID already. And that is a fatal kind of mistake, and quite common, I expect.
Here is the problem: I am both right and wrong (but more wrong). The code will work fine as long as my nebulous assumption holds. But who knows when it won’t? Maybe I will forget six months from now and call this function without a valid ID. Or maybe someone else will call this function without a valid ID. Or maybe some unrelated code will generate a bad ID. There are an infinite number of possibilities.
So, the $1M question is “Alex, you know what you should have done to check the ID. Why didn’t you do it?” In the more general case, the answer is a combination of a lot things:
Laziness. Writing defensive code is boring
Overconfidence. I have an overconfidence in my understanding of the code, and I know I don’t need to check the ID.
Procrastination. I know it needs to be fixed, and I will get back to it. If I remember.
Attention. The squeaky wheel gets the grease. This code works under all of our “user level” tests, so it isn’t clamoring for attention.
Missing requirements. Sometimes I have a vague sense of requirements in my head. Sometimes I have good requirements from a customer. Most often, I have a vague sense of requirements from the customer. Sometimes bugs are just requirements that weren’t stated originally.
Time. One of my talents is that I can develop code that works well, extremely fast. Sometimes software is only valuable if it is done by Monday, and useless if it is done on Tuesday. Defensive code slows down my thought process.
Now, I’m not trying to make excuses. None of these are really excusable. But I do believe they are common causes of hidden errors in code that don’t show up during initial testing.
In terms of fixing this problem, there is no silver bullet. Some things like Test-Driven Development (TDD) help immensely. Using SOLID development techniques is always a plus. But the whole thing is a spectrum of (faster/better/cheaper) and you get to pick two. For things like interplanetary probes or healthcare the cost of a bug may be astronomical, so you have to spend a huge amount of your budget testing, to get that bug probability as low as possible. For things like websites, an error may be less costly (and quick to fix), so you can spend less on testing.
There is no one right answer. Except that you can’t be 100% bug free.
I am closing out my one year experiment of using a virtual machine for development, and I wanted to share my results for people who might be considering the same thing. If you are lazy, here is the short version — using a VM to develop software has a lot of advantages, but it is not quite ready for prime time yet.
I started this experiment for a number of reasons. One was that I wanted to get more familiar with VMs, as well as with OSX. I got a new Mac Book Pro laptop and set up VMWare and Parallels on it to run my PC VMs. I quickly learned that 4 GB is not really enough to run a serious developer VM as well as OSX, so I upgraded to 8 GB, which was quite expensive. Initially, I did not like how Parallels worked, so I used VMWare. I also wanted to be able to move my VM to another machine, which was another reason to use VMWare. However, by the end of the experiment, I switched to the latest version of Parallels, which had more features, ran a little better, and also let me play some graphically intense games.
Environment:
MacBook Pro (2009 era) w/ 8 GB, 15″ screen
VMWare / Parallels for VM
There is a lot of buzz in the IT community about running VMs as servers, and the arguments are very compelling there. Most IT people I have talked to believe that the future for servers is in virtualization. However, not many people talk about using VMs on a client machine. If you can run a native OS, why run a separate OS inside it? Well, there are a number of reasons, some good and some bad.
Isolation of clients You can have a separate VM for each client, with only that client’s projects on it. When you are done with the client, you can archive the VM and go back to if if the need arises in the future. This lets you completely customize the setup for a particular client, and not worry about making breaking changes later. In reality, this was way too much trouble. It can take the better part of a day to set up a complete OS with all your developer tools, browsers, widgets, etc. Not to mention the licensing issues. Fail.
Isolation of OS versions I had a couple of arcane things that needed to run on XP. I was able to create a VM for XP and a VM for Windows 7, where I did my primary development. It was easy to switch back and forth when I needed to. I generally only had two active VMs at any time. A second advantage was it let me create a “baseline” machine configuration and occasionally reset to that. Win.
Isolation of concerns I was able to have my development machines “pristine” in that they were not cluttered with browser history, games, utilities I was messing with, etc. This helped to minimize the number of potential conflicts. Win.
Moving your VM to another machine The theory is great – you can put your “developer machine” on a memory stick and take it anywhere. VMWare provides a runtime for free that you can install on any machine. This does actually work, and I tried it out several times. However, it is really little more than a gimmick. First, it takes a long time to copy 30GB-60GB, and you have to copy it twice. Second, it just never came up. I never had a real reason to run my VM on someone else’s machine. Fail.
Running multiple machines This is one that I really wasn’t planning on. When you run VMs and a host VM, you are really running multiple machines. That is often very convenient. For example, your VM is thrashing because it is running some CPU intensive process, or it is rebooting. Well, you don’t have to just sit there and wait. You can pop over to your host OS and browse the web or do whatever. With multiple CPUs, the host OS will always have some CPU left. Win.
I also had a lot of fears about running an VM, some of which were true and some of which were false.
Would a VM have enough performance for development? In general, VMs are very fast, the run natively on the hardware (no emulation) and about 95% of the time I couldn’t tell I was running on a VM at all. Where it makes a difference, though, is I/O. Disk I/O is significantly slower, as well as USB. At one point I was copying a large USB drive (about 400 GB). Using the VM took about a day, while a native machine could do it in a few hours. Aside from I/O, though, performance is great. Partial win.
Would a VM be compatible with my peripherals? I was blown away by this. I threw a *lot* of different peripherals at my VMs, including some obscure biometric hardware. Both Parallels and VMWare handled them with no problem at all. Also, the VMs make it easy to move a device from a VM to the host OS. Win.
Would the VMs be reliable? I have had VMs crash, but they were always host OS issues (a VM can’t help with that). I was paranoid that I would get some file glitch and my “machine” would be unrecoverable. That never happened, even when I did the equivalent of a hard power outage on the VMs several times. Win.
Would the VM work with all my software? This is bread and butter for a VM, and they do it well. I ran a ton of different software on the VMs, and it all worked the same as it would on the regular machine. The one exception was some licensing code that was supposed to be tied to the hardware makeup. It was able to tell it was on a VM and disable itself immediately. That’s by design, though. Win.
Would I be able to control the VM adequately? The VMs give you a host of configuration options, pretty much everything you need. As one of the last things I did, I was able to set up a VM with an externally available IP address in order to test some code requiring Paypal to access my VM directly on the internet. Win.
So the big question is why am I ending my experiment, when everything worked so well? One main reason — compile performance. Compiling is I/O intensive, and as I mention it is pretty bad on a VM. On the big project I am working on now, a full rebuild takes about 30 seconds on the VM. On a native machine with an SSD, it takes about 2 seconds. (putting an SSD on a VM would be a waste because it is bound by the VM hardware layer) That time adds up, and is really personally annoying. Second, it does gobble RAM. I can better utilize 8 GB of RAM with one native machine that I can trying to run a native machine and a VM.
I do believe the VM is the wave of the future for client machines. There are so many compelling reasons for it, not the least of which is the abstraction of the hardware. Think if you could run your development machine (or whatever machine) in the cloud, accessible from anywhere. That’s an old idea, but I think we are getting close now.
If you have a related experience doing development on a VM, please comment.
I’m participating in a technology entrepreneurship program called ACTiVATE based out of Texas State University. It’s a great program and through it I have met many wonderful people. The program got written up in the Austin American Statesman yesterday:
