Month: December 2010
The TechStars Boston application deadline is 1/31/11. However, the early application deadline is actually 1/13/11 – anyone that applies by this date is eligible to come to TechStars for a Day in Boston on 1/19/2011.
Katie Rae, the new TechStars Managing Director is doing an awesome job. I just got a note that we’ve already gotten more applications this year than we had last year. Even more excitingly, they are covering a wide range of companies – some deep tech, social media, health care informatics, robotics, and ecommerce.
Boston has always had a wide range of early stage companies with unique characteristics, most notably robotics and network and system layer software, so it’s great to entrepreneurs from these segments show up. We’ve also got some fun surprises on new mentors for 2011 in Boston that match up with these segments that we’ll be announcing soon.
So – don’t wait – apply to TechStars Boston now! TechStars Year 3 in Boston is shaping up to be the best yet.
On the heels of all the noise around Groupon’s $100m financing at a $7.5b (billion) post valuation, I thought I’d put out a call for “old VC term sheets – prior to 1990.”
My partner Jason Mendelson and I are working on a book titled Venture Financings: How To Look Smarter Than Your Lawyer and VC. The final draft is due at the end of February (feel free to give us your sympathy if you happen to see us between now an then) and based on my previous experience with our publisher (Wiley) on Do More Faster, I expect it’ll be out by the end of Q211.
The basis for the book comes from the Term Sheet series that Jason and I wrote on this blog in 2005. We’ve updated the series for the current reality of 2010 (of which much is very similar to 2005, with some differences), talk about lots of different twists that have appeared, and tell plenty of stories to illustrate what the implications of various terms and financing configurations are.
As part of this, I’m looking for some early VC term sheets. I started by trying to hunt down the original Digital Equipment Corporation term sheet (or letter describing the investment) from AR&D to Ken Olson but came up dry. Today, as I was working on some stuff, I realized it would be interesting to look at some term sheets from the 1970’s and 1980’s in whatever form they are in.
If you happen to be in possession of an older VC term sheet – either for a company that was successful or one that was a failure – I’d love to see it. You can email it to me if easy, or drop me a note and I’ll tell you where to fax it. I’ll make sure I honor your request to keep it anonymous if you want me to (either you, the company, or both) but of course would love the ability to weave it into the book where appropriate.
As I embarked on my journey to learn python, I began by exploring a number of different approaches. I finally settled on using “beginner’s mind” (shoshin to those of you out there that know anything about Zen Buddhism).
Rather than just dive in and build on my existing programming skills and experience, I decided to start completely from scratch. Fortunately, MIT’s Introductory Computer Science class (6.00 Introduction to Computer Science and Programming) is available in its entirety – including all 24 lectures – on MIT’s OpenCourseWare.
I fired up Lecture #1 (Goals of the course; what is computation; introduction to data types, operators, and variables) and spent an enjoyable hour remembering what it was like to be in 10-250. If you want a taste, here’s the lecture.
The lectures are all up on iTunes so I’m going to watch #2 on my way from Keystone to Boulder this morning (Amy is driving). I’ve got plenty of reading to do and I look forward to diving into the problem sets.
While watching the lecture, Professor Eric Grimson reminded me that this was not a course about “learning Python”, rather it was a course aimed at providing students with an understanding of the role computation can play in solving problems. A side benefit is that I will learn Python and – in Eric’s words – “feel justifiably confident of [my] ability to write small programs that allow them to accomplish useful goals.”
Beginner’s Mind can be a powerful thing.
January’s Tech Theme of the Month is going to be Python. I realize it’s still December; I decided to get a head start.
Last month’s tech theme was videoconferencing. I learned a lot, including the unfortunate continued split between low end and high end and general lack of ability to have a single universal solution. Oh – and bandwidth still matters a lot. I expect by the end of January we’ll have much better videoconferencing infrastructure set up at Foundry Group with the single goal of eliminating some travel.
I’ve thought about learning Python for a while. I don’t code much anymore and I regularly find myself wishing I could do something with a simple UI and heavy back-end processing – mostly to move data between web services that I use via the web services APIs. I stopped programming around 1993 although I occasionally had to dive back in and support something that I had previously written until the late 1990’s, when I stopped for good because I simply had no time. As a result, the languages I feel like I have mastery over are BASIC, Pascal, Scheme, and Dataflex and the corresponding environment that I’m comfortable developing in ends with MS-DOS and Novell Netware. While I did stuff in plenty of other languages as a result of courses I took (IBM 370 assembler, SAS, Fortran) or projects I had to figure out (PL/SQL + Oracle, Paradox, dBase), I don’t feel like I did enough with these to claim mastery.
Every couple of years, I fuck around with a new language and environment. PHP is the one that has stuck the best and I can read it and hack around if necessary. But I don’t really like PHP – it feels sloppy and I constantly am having to look up syntax because it’s not comfortable to me. I went through a “ok – I’ll figure out Ruby on Rails” phase a few summers ago but stalled when I realized that Rails wasn’t a particularly practical environment for what I wanted to play around with.
Python may be a miss for me, but when I look at Python code I feel very comfortable with the syntax. A few folks that I know that are like me (e.g. not developers anymore, but were once, and occasionally bust out an IDE to hack on something) swear by Python. But the biggest motivation for me was that 6.01 is now taught using Python.
In 1984, I took 6.001: Structure and Interpretation of Computer Programs. This is the first computer science class most MIT students take. I had written a lot of software, including several commercially released products, almost entirely in BASIC (with a little Pascal and assembly.) 6.001’s programming language of choice was Scheme (a LISP dialect) and working with it was an epiphany for me. I continued to write commercial apps in BASIC and started using a 4GL called Dataflex, but my coding approach was heavily influenced by what I learned in 6.001. The abstractions you could build in BASIC, if you tried, were surprisingly good and Dataflex was a remarkably robust 4GL – very UI constrained, but very powerful (and fast compared to everything else at the time.)
So – if you look at my history, I’m comfortable with imperative languages. I got a good dose of functional programming from MIT but never did anything with it commercially. And I stopped developing software before object-oriented programming became popular. Python feels like a mix of imperative and functional when I look at it and read about it so I’m optimistic that I can use my regular programming muscles without having to fight through the OOP stuff that I don’t really know and doesn’t feel natural to me.
MIT has an IAP course (the MIT January session) titled 6.189: A Gentle Introduction to Programming Using Python. As with many MIT courses, it’s available on MIT OpenCourseWare so I’m going to take the course over the next month and see how it goes.
If you are a Python expert and have any suggestions for sites, tools, or blogs I should pay attention to, please leave them in the comments.
If you are reading this on my website you’ll see a new bar popup at the bottom of your browser. It’s the BigDoor MiniBar. If you are a regular reader of Feld Thoughts, check in and join the community.
We invested in BigDoor earlier this year as part of our Distribution theme. BigDoor’s goal is to “gamify” any website. They’ve built a very deep and rich set of functionality around game mechanics via a programmable API – things like checkins, points, badges, trophies, levels, and a virtual economy. For an example of a deep integration, take a look at Devhub or the summary article on TechCrunch titled DevHub Now Turns Building A Website Into A Game.
Three months ago at a board dinner in Seattle we discussed the idea of creating a much lighter weight implementation – basically something that a publisher like me could implement on my site without having to write any code. This lighter weight implementation, now called the MiniBar, actually uses the full BigDoor API but has a UX for configuration and implementation in front of it that makes it easy to set up BigDoor on your site within five minutes.
I’ve been an investor in a number of publisher-enabling businesses and have learned a lot over the past five or so years. I learned the most from FeedBurner, which was one of the first publisher-enabling businesses I invested in. They did a remarkable job of providing both a five minute implementation as well as a very deep programmatic API that allowed a publisher to control many aspects of the system. They encapsulated this in a brilliantly executed UX that made it easy to implement a variety of complex features with simple choices. This UX also allowed FeedBurner to regularly roll out new features without impacting the old UX.
With the release of the MiniBar, BigDoor is taking a page from the FeedBurner playbook. Now any web site, from a single blogger to a high end multi-site international media property or high volume ecommerce site can quickly (in under five minutes) implement a full game mechanic system, while preserving the ability to manipulate any aspect of it, either through the MiniBar UX (which will continue to evolve with every two week sprint) or the rich BigDoor game mechanic API.
The first MiniBar implementation includes Facebook Connect, an XP (experience point) system, a checkin system (throttled to allow checkins every 30 minutes), badges, a leaderboard, a daily deal (purchased with virtual currency – Feld Gelt – that you can earn or buy), and site sharing on Twitter, Facebook, Tumblr, and via email.
You’ll see this evolve regularly. BigDoor runs on a two-week sprint with a full release every two weeks. I’ve seen the next version of the MiniBar due in mid-January – there’s much more UI configuration control along with several new features.
If you are a publisher or blogger and want to gamify your site, give the BigDoor MiniBar a try – I’d love to hear your feedback (and check in on your site). And – if you want a direct connect with the company, just email me.
I nominate “platform” for overused tech word of 2010. Yeah, I whined about this a few months ago in my post Your Platform Is Not In My Space.
I hear the word “platform” in over 50% of the short pitches I get. A friend of mine who is working on a new startup that isn’t even funded yet (and he’s grinding on the financing) described his goal of “creating a platform for a-phrase-that-only-73-early-adopters-will-userstand.) Entrepreneurs everywhere describe the first release of their MVP (“minimum viable product” – for those of you that haven’t intersected with the Lean Startup movement) app as a “platform”. The first three pages of a google search on “platform” are 33% tech, 33% politics, and 34% other. At least Google image search is more accurate, for example:
Ahem – give me a fucking break. Yup – I get it – it’s great to be a platform. I give you Facebook and Twitter as examples. But real platforms are few and far between. And creating “a platform” is not necessarily the right first move for your brand new consumer facing application. Why don’t you start by being super useful to a bunch of consumers first.
I know I’ve been overusing the word “platform” lately – it’s like a weird brain infection that is hard to diagnose and then eliminate. I’ve found it – now it’s time to remove it from my vocabulary.
CES is just around the corner and I’m psyched to be going again this year. Toss in a BigDoor board meeting early in the week in Las Vegas and I’ll be getting my annual allotment of sin city in the first week of the new year.
Lots of my friends and a number of our portfolio companies will be at CES this year. Lest you think it’s just a VC boondoggle, one of my favorite moments of all time happened at CES in 2009 when my dad bought the very first Pogoplug. We went on to fund Cloud Engines (the company that makes the Pogoplug) which just closed a new $15 million financing that includes Softbank and Morgan Stanley Alternative Investment Partners. Oh – and they have had a totally kick ass year.
Last week, I noticed an article about Orbotix in Wired’s Gadget Lab titled Phone-Controlled Robot Ball, Like Marble Madness in Meatspace. Orbotix is going to be at the CES ShowStoppers event the night before CES begins (and at CES). As you can see from the article, Wired just challenged Engaget to a Sphero-off. As Paul Berberian, the CEO of Orbotix said to me in email, “it doesn’t get much more fun that this.”
If you are going to be at CES and are showing off something cool that you want me to see, toss your company name and booth number in the comments and I’ll make sure to come by on Wednesday or Thursday.
TechStars is currently accepting applications for the Boston program in the spring of 2011. Do More Faster and go apply now if you’ve been thinking about it.
After reflecting over the past few weeks on Turning 45 as well as Death and Dying, I’ve reached a conclusion that I’ve said out loud several times: “My life is most likely more than half over.” The singularity not withstanding, the chances, at least today, that I’ll live to be over 90 aren’t great.
Over the weekend, I saw two blog posts from friends – one from Joanne Wilson about her mom passing away titled Judy Solomon, Entrepreneur and one from Ken Smith (I’m actually close to Ken’s brother Keith, the CEO of BigDoor) titled A Eulogy for Elmer Smith. Both are beautifully written – Judy was 73 and Elmer was 97. Joanne starts off with a very insightful statement:
“Old enough to have lived a full life yet young enough to have had her life cut short. I always thought she would live to the ripe old age of 90 something, but life doesn’t always turn out as expected. “
Several of you recommended that I read Younger Next Year: Live Strong, Fit, and Sexy – Until You’re 80 and Beyond. It was one of the books I read during my week off the grid the first week of December and I enjoyed it a lot.
It had two key graphs in it. The first is the normal “human being decay cycle.” Basically, at the age of 45, most humans start a long, slow, gradual decay ending in death.
The second is the “desired decay cycle.”
The book talks about how to live your life from 45 forward so you experience the second curve. As Amy likes to say, there are usually only a few things you need to do to accomplish physical health (e.g. if you want to lose weight, (1) eat less and (2) exercise more.) In this case, it’s (1) don’t eat crap and (2) exercise six days a week, at least two of them with weights.
There’s a lot more in the book, including plenty of real medical, health, and physiology explanations from Dr, Harry Lodge (the co-author). But just internalizing these graphs along with the two tips from the book have enabled me to re-commit to the six-day a week exercise approach (at least two of them with weights).
I sure do like the second graph a lot better than the first graph.
As a user, how often have you thought “I wish this web service was faster.” As a CEO, how often have you said “just make it faster.” Or, more simply, “why is this damn thing so slow?”
This is a not a new question. I’ve been thinking about this since I first started writing code (APL) when I was 12 (ahem – 33 years ago) on a computer in the basement of a Frito-Lay data center in Dallas.
This morning, as part of my daily information routine, I came across a brilliant article by Carlos Bueno, an engineer at Facebook, titled “The Full Stack, Part 1.” In it, he starts by defining a “full-stack programmer“:
“A “full-stack programmer” is a generalist, someone who can create a non-trivial application by themselves. People who develop broad skills also tend to develop a good mental model of how different layers of a system behave. This turns out to be especially valuable for performance & optimization work.”
He then dissects a simple SQL query (DELETE FROM some_table WHERE id = 1234;) and gives several quick reasons why performance could vary widely when this query is executed.
It reminded me of a client situation from my first company, Feld Technologies. We were working on a logistics project with a management consulting firm for one of the largest retail companies in the world. The folks from the management consulting firm did all the design and analysis; we wrote the code to work with the massive databases that supported this. This was in the early 1990’s and we were working with Oracle on the PC (not a pretty thing, but required by this project for some reason.) The database was coming from a mainframe and by PC-standards was enormous (although it would probably be considered tiny today.)
At this point Feld Technologies was about ten people and, while I still wrote some code, I wasn’t doing anything on this particular project other than helping at the management consulting level (e.g. I’d dress up in a suit and go with the management consultants to the client and participate in meetings.) One of our software engineers wrote all the code. He did a nice job of synthesizing the requirements, wrestling Oracle for the PC to the ground (on a Novell network), and getting all the PL/SQL stuff working.
We had one big problem. It took 24 hours to run a single analysis. Now, there was no real time requirement for this project – we might have gotten away with it if it took eight hours as we could just run them over night. But it didn’t work for the management consultants or the client to hear “ok – we just pressed go – call us at this time tomorrow and we’ll tell you what happened.” This was especially painful once we gave the system to the end client whose internal analyst would run the system, wait 24 hours, tell us the analysis didn’t look right, and bitch loudly to his boss who was a senior VP at the retailer and paid our bills.
I recall having a very stressful month. After a week of this (where we probably got two analyses done because of the time it took to iterate on the changes requested by the client for the app) I decided to spend some time with our engineer who was working on it. I didn’t know anything about Oracle as I’d never done anything with it as a developer, but I understood relational databases extremely well from my previous work with Btrieve and Dataflex. And, looking back, I met the definition of a full-stack programmer all the way down to the hardware level (at the time I was the guy in our company that fixed the file servers when they crashed with our friendly neighborhood parity error or Netware device driver fail to load errors.)
Over the course of a few days, we managed to cut the run time down to under ten minutes. My partner Dave Jilk, also a full-stack programmer (and a much better one than me), helped immensely as he completely grokked relational database theory. When all was said and done, a faster hard drive, more memory, a few indexes that were missing, restructuring of several of the SELECT statements buried deep in the application, and a minor restructure of the database was all that was required to boost the performance by 100x.
When I reflect on all of this, I realize how important it is to have a few full-stack programmers on the team. Sometimes it’s the CTO, sometimes it the VP of Engineering, sometimes it’s just someone in the guts of the engineering organization. When I think of the companies I’ve worked with recently that are dealing with massive scale and have to be obsessed with performance, such as Zynga, Gist, Cloud Engines, and SendGrid I can identify the person early in the life of the company that played the key role. And, when I think of companies that did magic stuff like Postini and FeedBurner at massive scale, I know exactly who that full system programmer was.
If you are a CEO of a startup, do you know who the full-stack programmer on your team is?