Archive for April, 2011

E. & O.E.

Thursday, April 28th, 2011

Those are the three words you will find in a restaurant bill. Errors & Omissions Expected. Good acronym for trivia buffs.

Fast Company: Built to Flip

E.O.E. These 3 words were uttered to me by an entrepreneur, whom I bought a cup of coffee. He was apologetic when I told him that’s not the way to do things and he should be building a company to scale and reach milestones–not built to flip. I narrated some tid-bits of the cover story done by Fast Company magazine which was prophetic and foretold the dot com meltdown which happened months after that article was published.

Agreed that there is more money than ever flowing in India in certain sectors and raising angel money is easier than before. However, chasing the sectors which are attracting a lot of attention is wrong way to bet things (His logic for betting on those sectors–It may be easier to raise money).

Unfortunately, a lot of entrepreneurs in India are reading too much into the Silicon Valley funding & exit fire hose, which makes sense only in the valley because of the reasons we know. India is still a parched land in terms of high-tech early stage money; only 5% of total PE/VC is in Angel + Series A + Series B. Furthermore, of that pool a very small percentage is for Pre-Series A deals. India’s early-stage money is FFI (Funnel funnily inverted or Fully f**** inside-out). Think about it. Do you still want to be an Exit Oriented Entrepreneur?

[Interestingly, @brij and I exchanged tweets on this topic yesterday morning related to @cdixon’s post]

The kind of engineering team to be built this time

Friday, April 8th, 2011

This time the software engineering team will not have any Quality Assurance person. All the manual testing is being thrown out of the window.

In ancient days of internet software development, testing was all manual; point-click-verify, check the database etc etc. Thanks to evolution of tools for automation of software development tasks around (a) build, (b) automatic deployment and (c) unit testing; it has become possible to automate the task of deploying a codebase without manual testing. This is what is being called continuous integration, wherein quality control / testing is applied continuously instead of being done at the end of the development process.

Let’s look at a chart depicting the evolution of resource allocation. For the sake of simplicity only the resources of type (a) Dev (b) QA (c) Design (d) Admin are accounted. Over the years, the staffing requirements of QA has gradually reduced due to automated testing, etc. However, someone is still around to “play” the test-suite, collect the data, push the release out, etc.

Fig. 1. Engineering resource allocation for Internet product dev

However, I’m thinking, “Why not cut the cord for Quality Assurance staffing altogether?” Put an extra 25% effort in setting up a Continuous Integration server during the initial days and another 15% on an ongoing basis for writing test cases.

No QA on the team technique is followed in small startups who lack resources. But not because of 100% automation. There is still somebody pressing the buttons. Even worse, developers or product management  or even sales / marketing at times end up doing the QA towards the end of the cycle. In my previous role as a startup CTO, the T stood for Testing. We had some automation but often the bugs were shipped to customers, so I ended up doing QA. That was more than two years ago, and the tools have improved vastly.

The chart below depicts the grand plan.

Fig. 2. No QA but resources reallocated

OK, so no QA. What do we do with the extra money? Reduce the engineering budget? No way. Instead, let’s reallocate part of that to engineering and increase the design resources. Design has become important. Increasingly important. Garry Tan, who is a co-founder at Posterous, quit to become the Designer-in-Residence at Y-Combinator. Last year, the lead designer of, joined as the ‘Designer-in-Residence’ at Bessemer Venture Partners. A lot of emphasis is being paid on usability, experience, simplicity. So much so that a question was raised at SXSW; who are the real rockstars of tech startups, Engineers or Designers? There is no looking back on design, the bar is being raised continuously.

One word of caution however on the grand scheme of automation; the plan may only succeed if the test suite is well developed. Unless every feature addition results in addition of new test cases and careful orchestration of the moving parts, the guy with the T would remain the Chief Tester.