Wednesday, December 7, 2011
Twilio: Fueling Up for Growth
Twilio has been growing rapidly in the US and they recently launched in the UK for voice with text coming soon. In addition to geographic expansion, Twilio has also been adding awesome new services such as Twilio Client and Twilio Connect. We are excited to be supporting Team Twilio together with the fine folks from Bessemer with a $17 million Series C financing. Congrats to the entire team on a fantastic year!
Tags: twilio usv bessemer financing
Tuesday, December 6, 2011
Tech Tuesday: Programming (A Start)
Maybe I should have started the whole Tech Tuesday series with a post on programming since that’s why computers were created in the first place! In fact, thinking about programming in many ways precedes the availability of actual computers to carry out those programs. At the time that Babbage was dreaming up his Analytical Engine, Lady Ada started to formulate how a general purpose machine would be programmed. That was almost 100 years before the first truly programmable machines were actually built! Much closer to that date but still before he had access to a computer, Alan Turing in 1936 described an abstract machine (the Turing machine) that he then proved could compute anything a computer can do no matter how fast or complex a CPU, how much memory, etc it has (aside: that does not cover what a quantum computer might be able to do if we ever figure out how to make one work).
So what does it mean to program a computer? Somewhat flippantly: programming is telling the computer what to do. But given the pieces that we have put in place we can define programming more precisely as: creating a set of instructions that the CPU can execute to achieve a desired outcome. That outcome might be the computation of a number, the animation of an object on the screen, the manipulation of a text or — and this is the beauty of programming — pretty much anything else one can dream up. In the process of executing the program, the various parts of the computer work together as specified by the program. Data will move around memory and maybe to and from storage. If necessary, I/O devices will be activated. Possibly data will be sent or received via a network.
How does a programmer go about creating the set of instructions? In the early days of computers this literally involved hand picking instructions from the CPU’s instruction set and manually encoding these so that they could be fed to the CPU. But because of the work of theorists and the desire of visionaries we rapidly wound up with programming languages that were more easily accessible to humans and could then be translated by the computer itself into the instructions for the CPU. One such vision had always been to program a computer using simply spoken language and with Siri and Android voice actions we now have that as a reality — people are quite literally telling their phone what to do.
Whenever you program a computer in anything other than the actual machine code (the bytes that represent the instructions and addresses) you are using some kind of programming language. So called Assembly Language is barely above machine code. It is mostly a set of acronyms for the instructions with some ability to refer to program and memory locations by a name as opposed to an actual address. A program called an assembler is used to translate assembly language into machine code. Because writing assembly is really picking instructions by hand it takes a long time to write programs but affords the ultimate control over what code is actually executed which can be important for some cases, such as parts of a device driver.
Anything that’s more expressive than assembly is generally referred to as a higher level language. Among higher level languages there is still a huge range though from a language such as C which is closest to the machine end to a language such as Prolog on the other (Prolog deals with logical expressions). Higher level languages require some form of translation into machine code. This is handled by programs known as interpreters and compilers. As a first cut you can think of the difference between an interpreter and a compiler as the difference between having a simultaneous translator and a translated book. Essentially an interpreter reads the higher level language as it comes along and figures out what to do whereas a compiler takes one or more passes over the entire higher level language program.
In order for an assembler, interpreter or compiler to be able to do their work, the expressions in assembly or in the higher level language have to follow specific patterns which are known as syntax. That is of course even true when programming a computer in natural language in the Siri example above. If you say something completely ungrammatical, Siri will not know what to do.
I have found programming to be a deeply satisfying activity and will write lots more about it in upcoming Tech Tuesdays. When programming I can spend many hours without noticing the passage of time at all. Part of the satisfaction for me comes from how programming is a craft that combines writing and analysis/math in a wonderful way. But part of it also comes from the amazing amount of control I can exercise over machines which contrasts sharply with the many limits on control in the rest of our lives!
Tags: tech_tuesday programming
Monday, December 5, 2011
Let’s Kill the Quiet Period
Much of the regulation that we have in the financial markets (and other markets for that matter) predates the Internet. While there has been the occasional patch here and there, too many anachronistic concepts remain that should simply be eliminated entirely. My favorite example is the “quiet period.” As even the SEC notes on their own web site, the quiet period isn’t even found in federal securities law. Instead, as this blast-from-the-first-bubble-past article from Wired describes, the quiet period was born out of the Securities Act of 1933 (which was meant to avoid a repeat of the crash of 1929).
The idea behind the quiet period was essentially that once a company had filed a prospectus to go public it shouldn’t be able to provide new information that’s not in the prospectus until it has actually gone public. That may have made some sense at a time when a prospectus was something printed, bound and then distributed to the world. It makes zero sense today. If the company has additional information it can add this information to the SEC filing in near real time or simply even post it to its own web site in an easily accessible format (there should be a simple requirement that such information cannot be removed, only further amended).
The quiet period today is bad for both the company and the average investor. It’s bad for the company by opening the company up to attacks from competitors via the press to which the company cannot respond no matter how baseless or distorted the allegations are. We have seen this happen in a number of recent quiet periods. It’s also bad for investors as additional information disseminated to everyone would be useful. Instead, that information tends to be trickled out only to a few institutional investors during a so-called road-show.
Net it seems that the only people who are benefiting from this rule are IPO lawyers, investment bankers and large institutional investors. So much for the consequences of trying to protect the small investor and not leveraging the Internet. Instead of a road-show I believe companies going public should provide a livestream together with an ability to queue up questions over chat. The stream would be archived along with the questions. Wonder how long it will take for regulators to embrace the Internet for truly public information access for IPO candidates.
Tags: ipo reguation startups
Friday, December 2, 2011
SOPA as Prohibition (Darknets Are Bad For Society)
I am probably not the first to come up with this analogy (and I am on a flight without wifi, so I can’t look it up either) but it just struck me that there are big parallels between SOPA and Prohibition. How? In that the unintended consequences will far outweigh the benefits, especially when it comes to crime. Prohibition didn’t stop the consumption of alcohol. It just drove it underground. In doing so it not only supported the creation of a large infrastructure for illegal activity (e.g. gambling) but also made lots of everyday citizens complicit.
An ever harder crackdown on the sharing of copyrighted materials is now similarly fueling the creation of “darknets” - networks that are using the Internet solely as a transport layer but are otherwise disconnected (much like using the roads to transport alcohol during prohibition). I don’t mean to suggest that these new networks are being designed specifically for illegal activities but they will certainly make it much easier for those to take place More importantly, darknets will break much of what makes the Internet such a powerful force for good at the moment: the open sharing of ideas. If anything what we need is a softening of copyright and other IP enforcement to allow a further blossoming of this new public space.
One way to potentially accomplish this is to have a mandatory licensing scheme. We have such as scheme in place for Internet radio but not for on demand audio or video. Post prohibition anyone was able to set up a liquor store, but they still needed to get a license to do so. The legal framework switched from prohibition to regulation and the illegal activity receded. We need a similar approach to intellectual property. A recent report on copyright and IP commissioned by the UK government made a recommendation in this direction. P.S. Sorry, no links right now as I am writing on mobile.
Tags: sopa prohibition darknets
Thursday, December 1, 2011
Negotiating a Term Sheet
There have been many great posts about the various terms that go into a termsheet for a venture investment. As a result entrepreneurs are much better informed which is a good thing all around. I am still puzzled at times though at the approaches taken by both VC firms and entrepreneurs when it comes to actually negotiating a term sheet. Here are a few things that I have learned.
For VCs (I have written about the VC side before, but this seems worth repeating): Behavior during the term sheet phase is not an unreasonable predictor for later behavior. So avoid exploding offers or sending fully baked and signed term sheets. When it comes to justifying a specific term “we always get this” is not an actual argument. In a reasonable term sheet every term is just that: reasonable. So be willing to take the time to explain why that term is there. And if there is no good explanation, take it out. Don’t send a term sheet that your firm doesn’t stand behind or has some undisclosed contingency.
For Entrepreneurs: Don’t play your cards too close especially for an early stage investment. If you want to work with a firm and have an offer that you don’t like make sure to communicate. You don’t know what someone is willing to change unless you engage in a dialog with them. Beware the high bidder. They are much more likely to suffer buyers remorse the second you hit the first bump in the road (cf “winner’s curse” in auctions). Optimize in the following order: syndicate (who do you want to work with), terms, and only then price. Of course that prioritization applies only once the price is in striking range. If you are very far apart on price with a firm you like take the time to understand why and consider changing the size of the financing. Don’t simply assume that a gap can’t be bridged until you have engaged in a dialog.
For both sides: Whatever you do, keep in mind this is not about “winning” a negotiation. It is about starting a long term partnership on the strongest possible foundation. With that as guidance you are likely to behave very differently and everyone will be better off.
Tags: vc startups terms negotiating
Wednesday, November 30, 2011
Privacy and Facebook
So Facebook settled with the FTC over privacy and Mark Zuckerberg wrote another apologetic blog post (as pointed out by Liz Gannes this is his tenth). Part of the need for these apologies comes from Facebook’s aggressive approach to releasing features which at some level is admirable in a company of their scale. But what is really driving the problems is a fundamental conundrum about privacy in the digital age. Anything that was private a second ago can be made public by someone else with often little more than a click. One click public-making if you so want.
There is no doubt that this extremely powerful technology will over time transform our conceptions of private and public. I highly recommend Jeff Jarvis’s book Public Parts as it provides some interesting historical and cross cultural contexts. What the book makes eminently clear is just how much “private” and “public” are social constructs and how fundamentally they have changed with past changes in technology.
These large scale social changes, however, tend to take much longer than the underlying technology changes that drive them. So we now find ourselves in an in-between period. We have the one-click public-making technology but we still (mostly) have our previous notions of public and private. Facebook started out by incorporating these previous notions deeply into the system but it is difficult if not impossible to get to the kind of clear lines that people are still looking for in a system of Facebook’s complexity (e.g., what is the privacy expectation around something shared with friends of friends?).
What has worked much better for people to date is to have easily understood conventions around the privacy expectations for completely separate types of communication. If you text or IM a person your expectation is one of privacy. That’s the primary reason a site such as bnter hasn’t taken off yet. It goes fundamentally against the grain of people’s expectations of privacy for a particular type of communication. The same is largely true for email, which is why even smart people get caught in sending emails to reporters who then occasionally publish those as on the record conversations.
When we have settled into whatever our new social constructs will be (and I don’t expect that to be anytime soon), the discussions we are having now will seem as quaint as the debates over whether newspapers could publish photographs. I don’t know what exactly those new constructs will be, but I highly doubt that reflecting them in software will require users to make complex adjustments to privacy settings.
Tags: facebook privacy
Tuesday, November 29, 2011
Tech Tuesday: Operating Systems (Making It All Work)
I ended last week’s Tech Tuesday on Input/Output saying I might write next about programming in assembly language, but it has since occurred to me that I should cover at least one other high level topic first: operating systems. That seems more logical since the operating system (OS) is what makes all the parts of a computer system work together. In fact, I alluded to that last week in the context of the device drivers that are used by the OS to get data to and from peripherals such as a keyboard or a monitor.
Without an OS any computer system is really just a bunch of parts that are fairly useless by themselves. The OS handles such critical tasks as scheduling which program to run, reading from and writing to files (in storage), communicating over networks, accessing peripherals. Today most people have at least a couple of different operating systems in their lives because in addition to their personal computer they also have a smart phone — which is really just a portable computer. You might have a Windows laptop and a Blackberry OS phone. Or an OS X Macintosh and an iOS iPhone or iPad. Or a Linux Laptop and an Android phone. Or some other combination of these or some other OS altogether. And of course when you are accessing servers you are talking to another set of OSes such as Windows Server or Linux or some UNIX variant. Along the way some of the networking gear, which are really custom computers, have their own OS, such as Cicso’s IOS (yup just off by a capitalization) or Juniper’s JUNOS.
Now if you look at the list of things that the OS is responsible for at the beginning of the previous paragraph, you may wonder — if the OS is responsible for scheduling which program to run and if the OS deals with reading files, then how in the world does the OS itself get into the computer and start running when I turn the computer on? That turns out to be an important question. In the early days there was a simple answer: the OS was stored in so called read only memory (ROM) and when the computer started the program counter of the CPU pointed to the beginning of the code for the OS. ROM is a type of memory that retains its contents even without power but cannot ever be changed (written), hence the name.
But a modern OS is huge and also changing relatively frequently with new versions being released, so storing it all in ROM doesn’t work. Instead, what happens is that a tiny bit of code is loaded with the sole purpose of then loading more code which then loads the operating system from disk. That process is known as booting, which is derived from boot strapping which carries with it the wonderful image of pulling oneself over some obstacle by one’s own boot straps (or in the case of the Baron von Muenchhausen pulling oneself out of a swamp by one’s pigtail which in turn reminds me to write a post about Terry Gilliam some day). That tiny bit of code that gets loaded at the very beginning is known as the boot loader and was referred to in the comments on the previous Tech Tuesday!
If you are still skeptical (as you should be based on the Muenchhausen reference) you might say, but how does the boot loader get data from the disk? Didn’t you say last week that disk IO is handled by the OS? Ah, I failed to mention that thing known as the Basic Input Output System (BIOS). It is a bunch of code that does in fact sit in ROM or these days often Flash memory. It allows for primitive input output usually with a monitor (just characters, no graphics), a keyboard, a disk, and more recently also the network. Without that “hard wired” code the whole boot process could not work.
Every modern operating system consists of two fundamentally different parts. The so-called kernel and everything else. As the name suggests, the kernel is central and is where all the really hard stuff happens, such as switching between different programs or writing data to an output device. By everything else I mean programs such as utilities for searching through files (e.g. grep). I wrote this distinction intentionally somewhat vague, because if you look through the Wikipedia page on Kernels you find that a lot of OS design and development work has gone into figuring out what to put into the Kernel. No matter where the line is drawn, the programs that end users run on top of the operating system are all allowed to only access memory in what is known as user space or sometimes user land, which is kept separate from kernel space. Only code executing inside the kernel can access kernel memory.
Kernel programming is some of the most difficult programming there is. At Harvard there was an amazing class called CS 161 in which students essentially wrote an OS kernel from scratch. CS 161 even made it into the Social Network. For anyone truly interested in learning how an OS works nothing compares to going through that process and I would highly recommend getting Andrew Tanenbaum’s Operating Systems: Design and Implementation and start coding away (and/or get a copy of Minix to play with). In looking for a link to CS 161, I am somewhat dismayed to see that it seems like CS 161 was last taught in 2009. Can this really be true?. Maybe because it was most horrifically time intensive.
Tags: tech_tuesday operating_system
Monday, November 28, 2011
Hugo (Movie Review)
On Saturday, I went to see Hugo by Martin Scorsese with our two boys and my Mom who is visiting from Germany. It was my Mom’s first 3D movie and she was thoroughly enchanted by the effects, reaching for floating elements several times and loudly oohing. The 3D was used well throughout and with only a few “poke at the audience” moments that all more or less worked. As an aside: I noticed that the 3D glasses these days are less strongly polarized than I remember them and the movie felt relatively bright throughout.
Both our boys had read Brian Selznick’s book “The Invention of Hugo Cabret” and yet were thoroughly enthralled by the movie. Interestingly, neither of them realized that George Méliès was an actual historical figure. After watching the movie they still didn’t know but were thoroughly intrigued once I told them. Even without knowing this background, Hugo is a wonderful celebration of cinema that’s right up there with Cinema Paradiso.
One central idea for Hugo is cinema as both a manifestation and a source of dreams. This idea recurs throughout the movie for instance in the title of a scholarly book about early cinema, in an actual dream sequence and in a scene involving a clock that mirrors an iconic Harold Lloyd scene which appears as a film in the film earlier. There are also more subtle references such as a recurring scene of Hugo running through a corridor. I had just watched Inception again the night before and so that particular theme really resonated. Inception, like Hugo itself, is of course chock full of special effects which is what Méliès who was a trained magician had really pioneered.
Asa Butterfield in the title role of Hugo has amazing eyes reminiscent of Elijah Wood in Lord of the Rings but similarly registers more or less a single expression. Ben Kingsley is as per usual impressive as George Méliès — a man who has retreated into himself after being passed over by the very progress he helped create. Sacha Baron Cohen provides excellent comic relief as the overly strict and stiff Station Inspector with a secret.
Overall, one of the best movies I have seen with the kids in a long time. It works for both kids — based on enchantment — and for adults through the many references to movie making sprinkled throughout. Also, unlike the empty entertainment calories of so many kids movies, this one leaves a lot of lingering impressions and many points to revisit in subsequent conversation. When you go (if you haven’t done so already), see if you can spot the Scorsese cameo appearance (or — spoiler — see the image)!
Tags: movie review hugo scorsese
Wednesday, November 23, 2011
Giving Thanks (To Teachers)
Since I am taking tomorrow and Friday off from blogging, I figured I would write about giving thanks today. I am finding a great many things to be thankful for from good health to amazing work (that frankly doesn’t feel like work at all). But the specific thing I have in mind today is giving thanks for and to the teachers in our lives. I am always encouraging our children to thank their teachers, whether it is in school or for a sport or hobby. I tell them to think ahead of time about what they have learned from that teacher so that they can say something specific. It’s not just good discipline (what did I learn?) but I remember from my Dad who was a teacher that it meant a lot to him when students thanked him. Formal teachers are not the only ones we learn from though. And so this Thanksgiving I find myself particularly grateful for the many people in my life who have effectively been teachers for me at one point or another. I am using teacher very loosely here, but I am grateful those (friends, partners, even strangers) who explain something or simply challenge an assumption that I held or didn’t even realize I held. Thanks!
Tags: thanksgiving teachers
Tuesday, November 22, 2011
Tech Tuesday: Input/Output (Interrupts and Queues)
So far in Tech Tuesday we have taken a first look at how a computer does its work (processor), where it keeps data for quick access (memory), where data is kept longer term (storage) and how computers talk to each other (networking). Today’s topic is how to get data in and out of computers and to and from such things as printers, keyboards, screens, sensors, and more. These things are usually referred to as devices or peripherals. In the early days of computing many peripherals were relatively simple with early printers being not that different from typewriters (and the teletype combining keyboard input with printer output). These days when you buy a laser printer, you are really picking up a computer with its own CPU and memory! Still the basic problems of input/output have remained roughly the same.
For all peripherals there is a cabling and data transmission problem that’s similar to the one encountered in networking. There too I punted on this physical layer and I will do the same here. Suffice it to say that’s where things like USB (Universal Serial Bus) and HDMI (High Definition Multimedia Interface) come into play. I may cover these in more detail at some future point as they do contain a fair bit of complexity. For now, though I want to focus on two different problems related to devices that are critically important to understanding how computing works and has evolved: interrupts and queues. I will work through these in the context of a keyboard and a printer but the issues apply equally with other devices (including as it turns out the disks used in storage, which are really just another device albeit one so important that they got their own post and will get more posts in the future).
What’s going on inside the computer as I am typing this post? More specifically what happens when I press a key on the keyboard? Not surprisingly, each key is associated with a binary code for that key. When I press the key, the code for that key is written into a memory location known as the keyboard buffer. But as we have previously learned, memory itself is lazy, so how does the key code get there and how does the CPU know that a new value has been delivered by the keyboard? That’s where a so-called “interrupt” comes into play. The keyboard device triggers an interrupt when a key is pressed. That interrupt tells the CPU to stop what it is doing and jump to a different program — a program for handling keyboard input. That program usually does nothing other than read the code of the pressed key and write it into the keyboard buffer keeping track of which buffer location it is currently at an incrementing that location so that the next key that is pressed doesn’t overwrite the value of the previous key if that has not yet been made use of. The program that does all of that is known as the keyboard driver and is part of a computer’s operating system.
Now the keyboard buffer that I just described is really just a special example of something known as queue. Just like the people queue that forms at an ATM machine or an airline check in counter every new keyboard code that arrives lines up behind the ones that have arrived before. When writing output to a device the computer similarly uses queues. Let’s say I print this post to a printer. The computer will first write the output to a printer queue — an area in memory from where it will be transferred in portions to the printer (in the early days that happened literally byte-by-byte). Unlike “interrupt”, the word “queue” has made it into the visible user interface of most computer operating systems. There is usually some option to view which documents are in the print queue. Why does the computer need these queues? Well, if the CPU were not able to write output to a queue and have the printer driver take it from there, the CPU would not be able to do a lot of useful things while waiting for the printer. Of course the printer is much much slower than the CPU, especially when someone has forgotten to reload the paper! With the output in the queue, the CPU can be available to do useful stuff and whenever the printer needs a bit more data to print an interrupt causes the printer driver to be run. As in the case of the keyboard driver this is a low level program that just picks up some more bytes from the queue and sends them over to the printer.
So the key takeaway here is: computers use queues and interrupts to decouple peripheral devices from the CPU. The programs managing these queues and responding to the interrupts are the so-called device drivers. Both of these make for interesting challenges. What happens to whatever program that was executing when the interrupt occurred? What should the computer do when a queue is full but the device provides more input or the user tries to send more output to the device? Lots to cover in upcoming Tech Tuesdays, including a fair bit of interesting history around the licensing for device drivers and epic fights between makers of computers and peripherals.
P.S. Having now covered each of the basic building blocks at least once, I am open to suggestions where to go next. I was thinking about introducing the idea of programming and assembly language.
Tags: tech_tuesday input output interrupt queue
← Older Entries
Newer Entries →
