Collecting best practices

By February 22, 2010Venture Capital

Reading through emails and blogs yesterday afternoon I came to posts from engineers at Disqus and Twitter via Fred Wilson’s Code is craft post.  I read them partly because Fred recommended them and partly because I was interested to hear what presumably talented engineers at successful services like Disqus and Twitter had to say about improving the speed of a service and identifying the root cause of service problems respectively.

I’m interested to read these stories not because I am ever likely to need to do something similar myself (I am nowhere near that technical) but because I need to be able to recognise a good engineer when I see one.  That helps with figuring out whether we should invest in a company and in hiring senior techies into our existing portfolio companies.

I had two takeaways from the Disqus post:

  1. Separating the code which deals with dynamic data from code which deals with static data offers possibilities for performance improvement, including using CDNs
  2. For widget companies loading code onto a page asynchronously helps improve their customers page load times and is therefore a good thing

I will remember the Twitter post for its description of how they went about identifying the cause of a performance problem and having read it I will now experiment with asking CTOs to describe the last performance problem they encountered and how they dealt with it to see if it helps me form a view on how they would deal with problems they encounter in the future.  Additionally, there are two takeaways, that they helpfully put at the end of the post:

  1. First, always proceed from the general to the specific
  2. And second, live by the data, but don’t trust it

When I hear stories from companies that are consistent with these concepts and ideas I will take it as a good sign, and when their are contradictions or absences I will want to understand why.

As a VC I have to cover a lot of ground.  In fact, one of the reasons I enjoy this job is that it is one of the last bastions of the generalist.  I need to be conversant in best practice across sales, marketing, engineering, finance, and general management as well as form a view on markets and opportunities for startups generally.  Reading stories like these, and their equivalents in other areas (many of which I post on this blog) is one of the ways I try to stay on top of this challenge.

Reblog this post [with Zemanta]
  • gordonguthrie

    Live by the data, but don't trust it really is one of the key points. One of the classic WTF's? of performance problems is when you fix 'the measured bottleneck' and the whole system slows down instead of speeding up.

    A good winter olympics analogy would be if your bottleneck was getting bobsleighers onto the bobsleigh run. The 'bottleneck' turns out to be a critical smoothing function. Once you lift it and start spitting bobsleighs down helter-skelter then one single crash/problem and your whole system siezes up dead.

    The test I use with engineers is to see if they use the verb 'to optimise' without an indirect object. So a sentence like 'I optimised this module' is a warning sign.

    They should be saying 'I optimised this module against the user experience metrics' or '…in the context of end-to-end latency' or '…under these load conditions…' because either you are optimising to improve the customer experience or your wasting time.

    Optimising for its own sake (known in the trade as micro-optimisation) is a time-trap in which techie-noodlers can lose their lives tiny-tweaking and polishing their algorithms.

  • That's helpful, thanks.

  • Pingback: Las claves para crear una aplicación web exitosa | AndresRomero()

  • Pingback: Las claves para crear una aplicación web exitosa - AndresRomero()