development | Advice and Insights for Entrepreneurs | OnStartups

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Startups: Stop Trying To Hire Ninja-Rockstar Engineers

Posted by Dharmesh Shah on Mon, Aug 06, 2012

This is a guest post by Avi Flombaum. Avi is the Dean of The Flatiron School, an intensive program to learn Ruby on Rails in New York. He was formerly the co-founder and CTO at Designer Pages. You can follow him at @aviflombaum or @flatironschool.

Hiring technical talent is often cited as one of the most difficult parts of scaling a startup. Great companies are built by great teams so naturally, when it comes to technical talent, companies are competing harder than ever to entice the best of the best. The rationale you'll typically hear is along the lines of "a great developer is 10x as productive as a mediocre one." That might be true, but it is an impractical startup hiring strategy.

While companies fight tooth and nail over engineers with MIT or Stanford degrees with years of experience, as CTO of designer pages, my best hires were consistently entry-level developers that I developed on the job. Some companies, like Zendesk and GeneralThings have already realized this and are working with schools like Dev Bootcamp in San Francisco, The Flatiron School in New York (of which I'm a co-founder) and Code Academy in Chicago to hire their newly minted web development graduates. Aside from the fact that they're significantly easier to attract, there are tremendous benefits to the dev small

1. Cost- Starting salaries for senior developers have skyrocketed in the past few years. The average starting salary for a senior Ruby developer has climbed to $94,000 ($107,000 in Silicon Valley). Compare that with the average salary for a junior Ruby developer, $70,000, ($80,000 in Silicone Valley). At that rate, you can give a junior developer a 10% raise every year for 3 years at the end of which you'd have an experienced senior employee who's been with you that long and is still costing less than a new senior hire.
2. Attitude- Anyone that gets courted the way a senior engineer does today is at risk of developing a sense of entitlement (to put it lightly). When I hired 'rockstars' at Designer Pages, the requests became increasingly ludicrous. Senior engineers had four-day weeks, required conference budgets, and refused to adhere to the language and technology standards the company had established. They always knew best and felt that we were lucky to have them. Junior devs on the other hand, are hungry. They want to prove themselves and are eager to learn. And assuming you're fostering the right culture, are excited to be part of your team.
3. Turnover- High turnover is the easiest way to kill a product. In The Mythical Man-Month, Frederick Brooks discusses problems inherent in a system designed by a succession of leaders, each with his own style and ideas: "I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."
Great companies need great engineers who want to solve complex problems. But the majority of work being done on a typical web application does not require a team full of PhD's with 10 years experience, making it no surprise that senior engineers quickly get bored and seek out other opportunities. By hiring junior developers and ensuring they're getting the continual training and development that they need, you can ensure that they stay engaged and derive as much personal and professional value out of your company as your company derives from them.
4. Culture- A prerequisite for being a great programmer is a love of learning. Unfortunately, many senior engineers come with a lot of baggage; they want to work on specific problems, in specific languages, and have little patience for the inexperienced n00b. By hiring junior engineers, and giving them the training and development they need to flourish, not only can you align everyone's technical styles under a cohesive vision, you can more easily create a culture wherein it is expected for the senior employees to mentor and coach new hires, just as they were coached when they first started.
To be clear, this isn't true in every case. I happen to know plenty of incredibly humble, loyal, and generous (though not cheap), senior engineers. And if you're trying to build a better search engine, or solve the world's most complex data problems, you probably do need to recruit from the top 1%. Most companies though just need great leaders who can help their teams think through the difficult questions, and team members who are wiling to work together to implement creative solutions. The bottom line is that for most products, seeking out rockstar senior engineers is like hiring Picasso to paint your apartment.
So what's the best way to put this plan into action? Here are some things I found to be effective when developing junior engineers at Designer Pages:
1 - Deploy on Day One- Making engineers deploy code on their first day is the single best way to get them feeling great about their ability to acclimate and impact change in your organization. Companies like Etsy actually have a hard-and-fast rule that all engineers should deploy to production on day one.
2 - Assign Mentors- Lots of companies say they mentor their employees. I've found that unless this is systematized, senior employees get too busy to dedicate the necessary amount of time. Make sure every new hire has a mentor to pair with basically all-day for at least the first two weeks.
3 - Foster Productivity Early- The best way to sharpen a programmers skills is to write code. Junior engineers shouldn't be trying to learn legacy systems when they first arrive- let them work in as fresh a codebase as possible so they can get cranking right away.
4 - Invest in Training- Nothing will give you a better ROI on your time than making sure your employees are well trained. Create a learning plan for each hire for the first 3-6 months, complete with recommended reading, that applies to the projects they are working on.
5 - Be patient. :)
At the end of the day, when you hire junior developers, you are investing in people. You are creating a culture of growth, promotion, and learning that will pay for itself multiple times over. And it will also help you recruit the Ninja-Rockstars when you actually need them ;).
What do you think?  What's been your experience in terms of bringing on junior members to the team vs. the almost mythical ninja-rockstar engineers?

Article has 41 comments. Click To Read/Write Comments

Why PHP Is Fun and Easy But Python Is Marriage Material

Posted by Dharmesh Shah on Wed, Oct 27, 2010


I think a lot about choices and decisions at startups.  That is the life of a software entrerpreneur:  It’s a stready stream of hard work, occasionally punctuated by some really hard decisions.  The decisions that are hardest are not the ones where you have the least amount of information — they are the ones that are hardest to undo or reverse. 

By this defintiion, picking the language/platform to use at a startup is one of the harder decisions.  It’s very hard to change this decision.  Here’s the story of how I made not one but two big language/platform decisions, neither of which really worked out — and which I’m now paying the price for.  The good news is that the company did very well despite these mistakes for two simple reasons:  First, I didn’t make awful choices — just sub-optimal ones.  Second, success in the early days of a startup is much more about getting market validation and traction than anything else.  And, as it turns out, customers really don’t care whether your SaaS application is built in PHP, C#, Ruby or Python.

On with my story…

When I kicked off my startup, HubSpot, over 4 years ago (June, 2006) I wrote a set of articles on the topic of choosing a language/platform — specifically for startups.  At the time, I was trying to pick between C# and Python for my then fledgling startup.  The article was aptly titled, “Python vs. C#: Business and Technology Tradeoffs”.  The article was very widely read, and still continues to drive traffic (likely because it ranks #1 in Google for “Python vs C#”).HubSpot Labs Logo

I made some pretty good arguments in that article, most of which I still stand behind to this day.  We ended up picking C# at the time.  The decision came down to one strong, dominant factor:  I was more productive in C# than I was in anything else, and that mattered — a lot.  Why?  Because it was basically just me.  In the early days of a startup, you’re looking to mitigate unnecessary risk and get to market as fast as humanly possible.  Within reason, my general advice is  “go with what you know”.  By “within reason”, I mean if what you know is a relatively mainstream language (Python, PHP, Ruby, Java, C# etc.).  There are definitely times to learn new things and experiment with new technologies — the early days of your product development is not the best time.  Either you need to know the language/platfrom from soup to nuts yourself — or you need to have immediate access to people you can rely on, that do.  So, I picked C# and .Net — which frankly, if I had to do over, I wouldn’t have picked (more on that later).  But, based on my circumstances at the time, I thought I chose rationally, and I was solving for the company, not my ego or enjoyment.  The good news is that the mistake wasn’t fatal.  [Side note: Patrick, if you’re reading this, I’ll admit, you were right. I should write a follow-up article on this on the topic of trust].

A couple of years later, I was faced with a different decision.  I was working in HubSpot Labs.  HubSpot Labs is a “startup within a startup”.  We don’t have a written charter for HubSpot Labs (because frankly, I’m not exactly sure how to write one of those, or if I did, who would read it).  But, the idea was to build cool free tools (see  These tools pulled in website visitors, increased visibility of HubSpot, and helped us get some interesting data that we used to benefit our core business.  At the time all this was happening, I was trying to decide between PHP, Python and Ruby.  I knew I wanted a dynamic language, and I had whittled things down to those three choices.  I picked PHP, and Python was my second choice.  Though Ruby/Rails would likely have been fine too, there’s something about it that I just found unnatural.  If I had a dog, the dog would bark at the Ruby code.  Python just feels more “natural” to me.  But that's likely related to my C/C++ background.  But, I digress.  Back to why I chose PHP: Main reasons were: 1) It was easy to get started.  2) It had decent OOP support.  3) There were lots of other people using it.  4) It was lingua franca on the web.  The language served me well.  It was an easy transition from my C++/C# days, and combined with an MVC framework like CodeIgniter, things weren’t too bad.  I actually had fun developing in the language, and after the first few months, I felt that the code I was producing was about as good as some of the code I’m most proud of throughout my professional career. 

I have a love/like relationship with PHP.  Sometimes I have good days, and sometimes I have great days.

During my 2+ years of PHP development, I launched a bunch of web applications.  Cumulatively, they’re getting millions of page views a month now.  Not bad.  No major issues.

So, you might then be wondering, why switch away from PHP and move to Python now?  Don’t I have better things to do with my time?  Did I give in to peer pressure or somehow decide I wanted one more chance at being one of the “cool kids”.  I’ll attempt at answering some of those questions.

Why HubSpot Labs Is Switching From PHP to Python

Here are some of the tradeoffs (PHP wins on some fronts, Python in others), for those faced with the decision now.  Note:  The context here is a startup that is a bit further along (HubSpot was 2 years old and had about 50 employees at the time of this decision).  But, some of the arguments still apply, even if you’re earlier stage.

1. Python is well designed, PHP is not.  Although PHP is a completely workable language — it’s still not an elegant language.  In the short to mid-term, that’s not a particularly big problem.  Any experienced developer that can create great software can likely also write really good software in PHP.  (I’m talking about PHP 5+ here — and ignoring all the ugliness that came before).  But, there are limits.  I’m not particularly bothered by the weird idiosyncracies of PHP (the “needle vs. haystack” problem).  I can get over that pretty quickly.  It’s the other stuff — which is deeper and more nuanced.  As a “classically trained” developer (undergrad CompSci), I appreciate that Python gets a bunch of the language stuff “right”.  It’s about how reflection is implemented.  How functions are first-class objects.  It’s all the little things, which in aggregate, make for better cleaner, more elegant code.  Although it’s perfectly possible to write good code in PHP, it’s much easier to write great code in Python.  It is clear that Python was architected to be a robust, well-designed and well thought-out language.  PHP “just happened”.  Not to knock PHP (I actually love working in PHP) — but Python is just a better language.  [Note:  I still am viscerally troubled by the using whitespace to indicate code structure, instead of just using braces like the rest of the sane world, but it’s a relatively minor gripe].

2. Python has a “clear” web framework winner:  Although conceptually I like having choices (and I believe in openness), practically, I really, really like standards.  All things being equal, I much prefer that all of us are working with the same frameworks and libraries.  Python mostly has that with Django.  It’s close to the de-facto choice for web frameworks in Python.  Maybe not quite as dominant as Rails in Ruby-land — but close.  Contrast that to PHP where we have Symfony, Zend, CodeIgniter, Kohana — and others.  On the one hand, this kind of competition is good.  I’m sure they’re all great frameworks (I use CodeIgniter right now), but the fact that there’s no clear winner means that the market is fragmented.  And, fragmentation is bad.  It’s particularly bad when it comes to web frameworks.  The learning curve these days is not a new language (it takes a proficient programmer just a few days to get her arms around the basics of a new language).  The learning curve is with the framework.  The deeper and richer the framework is, the more there is to learn.  Don’t get me wrong, I love frameworks (dating back all the way to the Object Windows Library that Borland had for TurboPascal).  Frameworks have an upfront cost, but provide a ton of value long-term.  But, if there are a bunch of different frameworks floating around, the odds that any given person is working in the same framework you are lower.  And as such, getting someone new up to speed takes longer.  In Python land, the clear web framework winner is Django.  This means that if I find a great Python developer for the team (more on this later), they’ve likely used Django.  That makes life much easier. 

3. PHP is lingua franca in the world of the web.  One of the the early reasons I picked PHP, which is still true, is that it has become lingua franca on the web.  If someone releases a new API, and provides a “wrapper” for convenience, the first language supported will likely be PHP.  If you’re looking to build WordPress plugins, you’re going to be doing it in PHP.  In fact, many of the biggest open source projects out there, that you might consider leveraging, are based on PHP.  So, knowing PHP is a very, very useful thing.  My advice is that even if you do decide to go with Python — be at least “reasonably fluent” in PHP — it’ll come in handy.

4. Low-End Web Hosting is a non-issue.  Many people make the argument that PHP is a great choice of platform for startups because you can find a $9.99/month hosting provider that supports PHP.  No need for higher-end hosting and you save money.  I think that’s a poor reason.  Yes, it’s nice to know that there are thousands of hosting providers out there that all support PHP, and that you can get hosting really cheap as a result.  But, if you’re picking a language based on spending $10/month vs. $50/month or $100/month — you’re focused on the wrong thing.  Assuming that you stick with your low-cost provider for 18 months (a long time in startup-land), you’ll have maybe saved $900.  That’s just not a lot of money.  My advice:  Recognize that there are things like Amazon EC2 out there now, and over time, it’s going to be just as easy to spin up servers for Python as it is for PHP. 

5. Not all Python fans are fad-focused elitists .  One of the arguments I hear continually online goes something like this:  “PHP is a perfectly fine language, and folks pushing Python are just fad-focused elitists that want to work on the latest cool new thing, instead of just picking what works and focusing on building apps that solve customer problems.”  I’m paraphrasing a bit, but that’s the gist of it.  I can see why people sometimes feel this way.  Lets say you’re something like me:  You’ve learned PHP and used it to build and launch “real world” apps.  For you, the cost of change is high (maybe even prohibitively high).  Really hard to justify the change, because though you might grudgingly admit that Python is better, it’s not better enough to warrant switching.  You’ve got a startup to grow, you can’t be bothered with trying to join the cool kids.  But, I’m to advocate for some empathy here.  Lets say you were on the outside looking in (i.e. you’re a gifted developer looking to join a cool new startup).  Since you’re really good, and demand for great developers always exceeds supply, you essentially get to pick where you want to work.  All things being equal, you’re going to pick the place that is doing Python vs. PHP.  Of course, not all things are equal, and you might actually pick the startup whose business you think has the best chances of success or whose founders you like and respect.  But, often, it’s hard to know that stuff upfront, so you focus on what you do know — that developing in Python’s a better “bet”.  I wouldn’t fault people for solving for their self-interest and preference.  They’re not trying to talk you into switching, they’re just saying that it matters to them.

6. Low Learning are less important than high ceilings.  If you’re in the software development business as a career choice (i.e. you’re going to do it for a long time), then the larger consideration should be what’s going to create the most value for you long-term.  Some languages, like PHP, have very low learning curves — it’s super-easy to get started.  And, that’s awesome.  It’s easy-going, fun, and you feel super-productive (especially if you’re making a big change to something new).  But, once you get past that initial dating period, you need to think about your future.  You want to forge a relationship with a language that will be long-lasting, rich and deep.  A language that brings the best out in you — over the long-term.  Apologies for the strained metaphor here — but it had some resonance for me.  So, back to the title of this article:  PHP Is Fantastically Fun, But Python Is Marriage Material.  Apologies for the strained metaphor, but it resonated with me.  I’ve been programming for a long time, it’s my calling, and with any luck, I expect to do it for a couple of more decades. Since I'm going to get into a long-term relationship with a language, I figured Python's a pretty good bet.

Whew!  That ended up being longer than I expected.  If you made it this far, thanks for reading!  By the way, if you’re a gifted Python developer in the Boston area and looking to join what is quite possibly the best company to work for in Boston (we won an award, so it must be true), would love to connect.  The HubSpot developer interviews are a bit, um, rigorous, but I promise that you’ll meet some people that will have made the time spent worthwhile, even if things don’t work out.  If you’re interested, just drop me an email at {dshah} @ {OnStartups}{daht-com}.  By the way, in case you didn’t know, I’m the founder/CTO at HubSpot, and an all-around nice guy.  Just ask anybody. 

And, if there are any arguments you’d make on either side (PHP or Python), would love to hear them.  Don’t want to start yet another language war, but I’m fascinated by the topic of making hard decisions at startups, and this is one of the hardest. 

Article has 69 comments. Click To Read/Write Comments

Releasing Early Is Not Always Good? Heresy!

Posted by Jason Cohen on Mon, Dec 21, 2009

The following is a guest post by Jason Cohen. Jason's got a knack for stirring pots and getting us thinking a bit.  And, thinking is a good thing.   Even when the thinking makes me awfully uncomfortable and goes against my strongly held beliefs.  I couldn't be a stronger advocate of "Release Early, Release Often", so it took a bit of effort to post this article "as is".  But, as I hope you'll see, Jason does make some pretty good points.  Well worth debating -Dharmesh

[UPDATE: I originally stated that Eric Ries was a proponent of "Release Early," but I was completely wrong.] OnStartups No Hear

You can't throw a stone in the blogosphere without hitting someone arguing in favor of releasing software as early as possible. The idea is that it's best to push new software onto potential customers before it would be traditionally considered "ready."

Here's the general line of reasoning: In the beginning, you have a theory about who your customers are, what their pain is, what your product needs to do, and how it will be used. But it's just a theory, and it will always be wrong. That's OK! It's life.

Since you're wrong, your v1.0 is really just a foil to get people talking. Therefore:

  • Don't add a lot of features, because you don't yet know which features are actually needed.
  • Don't fix every bug, because half of this code might not be here in a month.
  • Don't pretty up the user interface, because it won't look anything like this in a month.
  • Don't obsess over the customer workflow, because it will change completely in a month.
  • Don't worry about scaling, because you won't have that many customers for a while.
  • Don't worry about architecture/extensibility/documentation because most of your code will be different in a month.

Now in general I agree with this line of reasoning, but I don't like how one-sided this discussion is. Even a casual glance through this discussion of the subject shows that people -- me included! -- are recommending this strategy as a knee-jerk reaction.

So for the sake of thoughtful debate, I'd like to present the case against.

The best ideas aren't built by consensus

Would the iPod have been invented if it were built by iterative customer feedback? I doubt it:

  • Do you want a portable music device without a radio? No.
  • Do you want a battery-powered device in which you can't change the battery? No.
  • Do you want a portable music device without Bluetooth? No.
  • Do you want a wheel-based user interface which you don't already understand and which makes certain operations confusing? No.
  • Do you want it to take 5 clicks to toggle "shuffle," one of the most-used functions? No.

Apple doesn't ask customers what they want -- they just go invent awesome stuff. People complain, sure, but in the end the success of the iPod and iPhone is undeniable.

In general, disruptive products by definition cannot be built by consensus. In fact, it's well-known that "design by committee" is a sure-fire way to get mediocre design.

Small, incremental changes pulled by customers blind you to bigger, better ideas.

You're misinterpreting the 80/20 rule

The typical 80/20 rule is: 80% of your customers use just 20% of your features.

The "release early" folks take this to mean: Just implement 20% of the features you think you need, because if that's good enough to get 80% of your sales, this is a much simpler, efficient, and therefore profitable way to operate a software company.

But this interpretation is wrong! To spell out the 80/20 rule more accurately: 80% of your customers use just 20% of your features, but each customer uses a different 20%. That implies you need more features, not fewer, otherwise there won't be enough for the various use-cases for your software.

Take Microsoft Excel. Every person I talk to uses a different subset of functionality. Some people are experts at PivotTables whereas others have no idea how they work. Some people can't live without the database connectivity stuff whereas others don't know what a database is. Some people drive key business data using conditional formatting, some people know just enough Visual Basic to save themselves hours of manual labor, and some are experts with the charting system.

The point is that you can't just remove 80% of the features from Excel and expect 80% of the people to still be happy.

Mock-ups are faster than code iterations, without some of the drawbacks

There's a variety of software and techniques for mocking up applications, both web-based and desktop. Mockups can typically be built in a matter of days and put in front of customers for feedback. Iterating with fake screenshots is always faster than actually messing with HTML, CSS, and back-end code.

Once the mockups for v1.0 are set, actually writing v1.0 is fast because you know the goal ahead of time. The complete cycle is faster than if you started coding in the first place, and the code is cleaner because you don't have traces of major false-starts. (Think database migrations, CSS styles, extra AJAX routines, unused dialogs.)

Releasing too early can ruin your reputation

When your first version is sub-par, you'd better hope very few people find out about it.

Back to Apple: The iPod worked on day one, but back in the 90s the Newton didn't. The Newton (the world's first PDA) was hailed as a revolutionary technology (just as the iPod and iPhone would be), but it didn't work well. In particular, the handwriting recognition sucked and there wasn't a lot of apps.

It never recovered from its early reptutation as "doesn't do a lot, and what it does do doesn't work well." Even when that was remedied, it was too late.

The typical counter-argument to this is that "release early" doesn't mean "release with lots of known bugs," but rather "release with fewer features." But we all know the difficulty in separating a "feature request" from a "bug report" -- what a customer sees as a devistating lack of functionality (bug) you say is missing by design (feature).

Ignoring architecture creates waste

Software architecture is something the end-user never sees, and is therefore usually cast aside in the arguments for releasing early and collecting feedback. But incorrect choices in architecture can bite you later on, causing an immense amount of waste, possibly enough to sink the company.

It's true that most companies don't survive, and therefore having a growing user base with a problematic architecture is "a good problem to have." But it's also true that an ounce of prevention is worth a pound of cure.

Take Twitter. Their scalability problems are legendary. Suppose they didn't have billions of dollars in funding to throw expensive people and hardware at the problem? It's not hard to believe that continuing scalability problems would have sunk their ship.

Or take Netscape. The architecture problems with their browser were so severe it required a rewrite, which took so much time and effort the product (and company) died.

Of course this doesn't mean you should dwell on architecture for six months before working on features, but it does mean you shouldn't just ignore future maintenance issues for the sake of releasing a month sooner.

Untrue: "The worst thing you can do is built an unnecessary feature."

This is frequently used as an argument for releasing early. The logic goes: Every feature is effort. Not just in creating it in the first place, but debugging it, testing it, training customers on it, integrating it into all other features, supporting it in the user interface, covering it in the user's manual, and keeping it even as the product's focus changes. Therefore, never add a feature unless it's absolutely necessary.

I agree unneeded features are a major expense, provided you retain them in the product. But having incorrect architecture is also expensive, yet the "release early" folks tell us that expense is OK!

The fact is, you can change or even completely remove features that have become albatrosses around the neck of your tech support and product evolution. The "release early" argument also includes frequent iterateration, morphing the software as evidence suggests. Changing and removing features is simply a part of that, and doesn't imply that releasing early is smart.

In fact, adding features is one of the few ways to test what customers actually want, because:

Customers are notoriously bad at providing feedback

Sometimes users will tell you that they want a time/date-based voting widget they can send by email, when what they really mean is that they need to coordinate schedules.

In my experience customers are terrible at deciding what features they need, which features they use, or how features should be altered. They're much better at describing what's difficult in their life, what frustrates them, or what takes up a lot of their time.

Customers aren't even good at explaining why they did or didn't buy your product. From Jo Owen:

My research showed customers thought they were rational purchasers of video cameras: it was all about price and performance.

But when I interviewed them as they left a store, they were often unclear about how much they had actually paid for the model after splashing out for warranties, batteries and accessories and sorting out a financing plan. They were also very confused about the relative performance of different models.

Of course it's necessary to gather as much feedback as possible from both customers and lost-sales! But it's not clear how accurate the feedback is or how to weigh it against your own vision and goals for the product.

Relying on unreliable information as the primary driver of product decisions is unwise.

What do you think?

In the end, of course it's better to have more feedback than less, better to be more agile than less, and better to have technical debt with a successful product than a failed product. However, it's just not fair to present only one side of the argument!

Do you have more arguments either way? Do you agree we're taking "release early" a little too far? Leave a comment and join the conversation.  Or, if you've got a question, you can post it on

Article has 69 comments. Click To Read/Write Comments

What Is The Opposite Of A Vacuum and Should You Develop Software In It?

Posted by Dharmesh Shah on Mon, Feb 04, 2008

Chances are, that if you've been involved in the creation of software or any kind of product, you've probably heard the advice: "Don't develop in a vacuum".

A vacuum is a space that is essentially empty of matter (according to Wikipedia). It's a philosophical concept because practically it is not possible to have a space that is completely "empty". But, I like to deal in abstractions anyway, so that's good enough for me. "Don't develop in a vacuum" generally means not to go off and write code in the absence of customer feedback. This should not be particularly controversial advice. Developing software without knowing whether users will like it, based purely on speculation and conjecture doesn't seem particularly smart. I've never met a single person that has said: "You should go build your product in a vacuum!"

So, I think it's good to not develop in a vacuum and ask users what they think as early as possible and as often as possible. But, it's great to actually be users of the product yourself. This advice has been widely circulated too. If you build something you would use yourself, your chances of success go way up. The reason is not particularly complicated. It's more efficient to have conversations with yourself than it is to try and go find users. There's a lot less lost in translation as well. Rumor has it, the most successful products at Google (like GMail) are the ones that Google employees actually use.

So, if developing without user feedback is developing in a vacuum, then what's the opposite? Developing under infinite pressure? I'm not sure, and I'm not smart enough to stretch this analogy along this particular dimension. But what I do know is that "developing for yourself as a user" starts to present risks at a certain point.

Let me give you a real world example. My startup, HubSpot, develops inbound marketing software. For purposes of this article, it's not necessary for you to know what that means. Lets just say that many businesses need it as it helps find more paying customers and increase sales. We originally started building the product because we had the problem ourselves, and couldn't find a reasonably good solution. So, we built something we thought we'd use ourselves. And we do. We don't just casually use it either. We're extreme users. We run our blog on it. We get sales leads from it. We track marketing analytics on it. We live inside our product. We could not imagine life without it. Most of the time, this is a really good thing -- except when it's not.

Here's when it's not: At a point, you have to stop and ask yourself how representative you are of your potential market. If you're a lot like them, then you can get away with having conversations with yourself pretty often and not lose sight of the customer too much. If you're not like them at all, conversations with yourself are not productive. My startup is somewhere in between. Although we resemble our target customers a lot (we're a small business with 25 employees, we sell to other businesses, and we have real marketing people on staff), we're not a perfect fit. Most of our customers are not as technical as we are, don't read SEO blogs all the time and actually have lives . But, the biggest difference is that we know too much. Not that we're smarter, but we're just around the problem too much. We live it too much. We have people that think about nothing else all day. Hence, it's easy to over-complicate the product because it seems "obvious" to our internal users. They fly right through the new features. The solution? Go get good, honest feedback from real customers/users whenever you can. There's no substitute.

Summary: Don't develop your product in a vacuum. If you can, be your own customer. But remember that conversations with yourself can only go so far because you know too much and it's unwise to try and pretend that you don't.

What do you think? Are you your own customer? Have you hit the limit of how much feedback you (as a company) can give yourself? Would love to hear your thoughts in the comments.

Article has 6 comments. Click To Read/Write Comments

LinkedIn API "Sometime Next Year": 6 Words Of Advice

Posted by Dharmesh Shah on Mon, Dec 10, 2007

I came across on article on TechCrunch this morning announcing an update on Linkedin.

I think it's great that LinkedIn is continuing to talk about an API.  But, here's why I believe they're missing the boat on this stuff:

1.  Moving Too Slow:  The last update we heard on the LinkedIn API was June, 2007.  That's over 5 months ago.  Sure, I understand some of these things take time, but this is one of those clear examples where capturing mindshare early is important.  Hundreds of developers are making decisions right now as to where to invest their time, energy and creativity.  How many developers will spend the time building on Facebook -- and as a result, likely not switch to LinkedIn?

2.  Not enough information:  If the goal is to attract lots of developers to the platform, there likely needs to be more information than availability than "sometime next year".  If the goal is not to attract lots of developers, then I don't know what the goal is.

3.  Where's The Creativity and Innovation?  Right now, there's only a single identified partner, "BusinessWeek".  In today's day and age, brand name partners are still useful, but I think LinkedIn would have done better with a list of half-a-dozen companies (maybe even including a couple of startups) to apply some creative use of the API.  I've got a bit of a bias here, as I'd love to include some LinkedIn-powered data into WebsiteGrader, our free tool for internet marketing analysis

For some reason, it just seems that LinkedIn is taking a very "old school" approach to this.  Rather than putting something simple out there as quickly as possible, that lets people tinker, experiment and create, they're seemingly working on something "perfect" and only trickling information out to those that care the most. 

I have just six words of advice for LinkedIn:  Release early.  Release often.  Engage passionately.




Article has 4 comments. Click To Read/Write Comments

Startups and The Problem Of Premature Scalaculation

Posted by Dharmesh Shah on Mon, Dec 03, 2007

Early-Stage Startup: "We've designed the system to handle millions of users and be fault-tolerant so that there is no single point of failure and can assure our users of 99.999% uptime. We're prepared!"

Me: That's premature scalaculation. You're worrying about scalability too early. Don't blow your limited resources on preparing for success. Instead, spend them on increasing the chances that you'll actually succeed.

Apologies for the metaphor, but I wanted to use the word "premature" and decided to leverage the most widely recognized phrase with that word in it.

In startups, the technical founder often wears his skills as an architect of scalable systems as a badge of honor. Lots of time and money is spent making sure that should the company ever hit the spectacular success that everyone on the team knows is inevitable, the system (software and infrastructure) will be able to handle it. Quite often, this is misguided.

In the early stages of a startup, whether you're venture-backed or not, the primary constraint you are dealing with is limited resources (time and/or money). These resources should be spent trying to figure out what is going to work and not on intricate software designs, code optimization and infrastructure upgrades. Should the company indeed succeed beyond your wildest dreams, that's a high quality problem and more resources will likely become available as a result.

One of the reasons why startup founders so often spend too much too soon on scalability is that it is satisfying to do so. You can spend resources and have something to show for it. It is also easier to take credit for tangible progress. "Hey, we just tested the system last night with a million users and it didn't crash!". Or, "We just upgraded our hosting infrastructure so we can guarantee our users 99.999% uptime!" It's also useful to tell potential investors. However, it is much harder (but usually much more meaningful) to spend resources on things that are not quite so black and white: like learning about your market, putting a few more iterations of the software out there, finding more users/customers. All of these kinds of activities are much more frustrating because they're so much harder to control.

While writing this, I came across an older article (Dec 2005) on the topic of scaling from the 37signals blog: Don't Scale: 99.999% uptime is for Wal-Mart . David does a great job looking at the practical side of the issue. Given that he's part of a team that went on to support hundreds of thousands of users (and lots of paying customers), I think his perspective is highly relevant. David went so far as to leave the first comment to his own article as a pre-emptive strike against the inevitable backlash:

"The preemptive strike: Not worrying too much about scaling doesn’t mean building Basecamp on an Access database with a spaghetti soup of PHP making 250 database calls per request. It simply means having a profitable price per request, chilling the f*ck out, and dealing with problems as they arise."

As a tech-founder myself (and a career software guy), I have to reiterate David's comment above. I'm not suggesting that you create a crappy system and ignore fundamentally good practices. Just don't go overboard on the optimization too early in the game.

Once again, my advice: Don't fall into the trap of spending your limited resources on planning and preparing for success. Instead, spend them on things that will actually increase your chances of success.


Article has 17 comments. Click To Read/Write Comments

Why You Should (Almost) Never Rewrite Your Software

Posted by Dharmesh Shah on Mon, Oct 29, 2007


Software startups are fun. In the early days, you have an idea, and a few developers (usually including one of the founders) cranks away and manifests that idea into an application that sort of works -- every other day, except Mondays, or on days when you're giving an important demo.

Hopefully (if you're smart), you get the software into the hands of real people as early in the process as possible. If you're even smarter, you get some of these people to part with money in exchange for suffering the pain and agony that you're going to invariably subject them to. This getting money from your users is called "selling software" and although it seems quaint in this age of advertising-driven business models, it used be all the rage back in the day, trust me.

As time goes on, you continue to get users (and possibly customers), and keep trying to make the software better. You work on two kinds of things: new features and bug fixes. You work a lot. Crazy long hours are spent. If you've been listening really hard to your users and doing something about the problems, then one day, you'll wake up in the middle of the night in a panic and check on the servers because it's no longer acceptable for the software not to work on Mondays. You discover that the software is actually still up, but you decide to stay up and code some anyways, because you're already up and and might as well get that new feature in, because you have lots of users now. This is called "success". Congratulations!

Then, some months later (or the following Monday, whichever is sooner), you're going to start wondering whether what was built was really done "right". Will it scale? Did you pick the right platform? Did that developer you brought on mid-way into the process create a bunch of crap, but you were so busy, you didn't really know? You begin wondering for the first time whether you should consider rewriting the software from scratch. You start looking for good reasons to rewrite it all and start "clean".

To save you some time, I'll identify for you the most common reasons/rationalizations people use for rewriting their software. This will spare you the effort of having to come up with the reasons yourself.

Common Excuses For A Software Rewrite

1. The Code Sucks: Things have become harder to change. Every time you fix something, two new problems pop up New developers joining the company are starting to throw-up over what's there right now.

2. "We're So Much Smarter Now": The development team argues that they understand the problem so much better now and had they known from the start exactly what the market was going to need and the features that would have been required they would have architected things better. Now that they know, it's time to redo it.

3. We Picked The Wrong Platform/Language: New developers joining the team can't believe the idiocy of picking Java/C#/Python/Ruby/PHP/Whatever. How stupid and lacking foresight were the individuals making the initial decisions! Surely, the clear and better choice now is Java/C#/Python/Ruby/PHP/Whatever (i.e. something different than what was picked before).

Now, that we've got most of the common reasons identified, I'm going to tell you that in just about all cases (especially yours), you should resist the temptation to rewrite from scratch. Here's why:

Why Rewriting Is (Almost) Never A Good Idea

1. It Will Take Longer Than You Think: Despite what you may think, rewriting your software will probably take almost as long the second time as it did the first time. Sure, you have more information now on what you need to build, but this information is already dated.

2. Markets Change: Chances are, your market is not going to hold steady and wait for you to get done with your rewrite. While you're busily rewriting the same software again, things are changing. Competitors are coming in. Demands are different.

2. Existing Customers Become Frustrated: Existing customers are going to want fixes and features to the old stuff (the stuff you're getting ready to throw out). The best you're going to be able to do is hobble along on some old version of your software, make small fixes, make all sorts of promises to customers about why the next version is going to solve all their problems. You're going to sleep even less hours (if that were possible). There just won't be resources to maintain your existing software and work on the rewrite. Even if there were, you're probably then going to have to deal with two different versions of the codebase which creates a whole other set of problems.

3. Refactoring Can Cleanup The Code: If the code is indeed a mess, you don't necessarily have to rewrite everything all at once to make it better. Refactoring is a great way to do this, a step at a time. (Refactoring is changing the internal structure of the code without modifying its external behavior). The upside to this is that all along the way, you still have working software that you can change.

4. You Don't Control The Rewrite, It Controls You: One of the great things about refactoring is that you get to pick how much of your time you allocate to cleaning up existing stuff and how much you allocate to responding to new market demands. (And please spare me the excuses that you don't have the discipline to refactor, you're better than that). Should some massive change happen in your market (like a worthy new competitor), if you are refactoring a piece at a time, you have a fighting chance of responding. If you're in the middle of a rewrite, you're probably toast.

Clearly, I have an opinion on this topic. So, when *would* I advocate actually doing a complete rewrite?

Example #1: You decided to write your software in Lisp because you thought it would cool and you'd been wanting to learn something new for a while anyways, and you figured hey, "even if my startup doesn't succeed, at least I'll have learned something…". Later, you have this uneasy feeling that you didn't really make the right choice which is confirmed by the fact that none of the other developers you're trying to recruit to join you are actually smart enough to program in Lisp and those that are refuse to work for just equity and live on red beans and rice. And besides, though the software is brilliantly architected and designed, it was never quite, well, released. And despite the fact that your technical choices give you the ability to stand heads-and-shoulders above your competitors as you scoffed down at them, for some inexplicable reason, you ended up never actually making any money. [Author's note: I have nothing against Lisp, I could have easily contrived another example].

Example #2: There's some big technology landscape shift (like going from client-server to web-based computing) and your existing stuff just doesn't work well in the new world.

For more on this particular topic, I recommend Joel Spolsky's "Things You Should Never Do, Part 1" It's an oldie, but a goodie. One of Joel's earlier articles (from back in 2000), but still relevant, in my opinion.

So, what do you think? What are the signs you look for that would make a rewrite the right choice? Have you actually tried a rewrite before and lived to tell about it? Would love to read about your experiences and/or insights in the comments.


By the way, as I get ready to post this, Boston is celebrating a World Series victory. Woo hoo!


Article has 27 comments. Click To Read/Write Comments

How To Do It Right: 5 Things I Love About the Digg API

Posted by Dharmesh Shah on Thu, Jun 07, 2007


In December, I started work on a fun little project called Website Grader.  Over time, this went from being a fun, little project to a fun, big project.  Website Grader basically measures the marketing effectiveness of a website by looking at a variety of different factors.

Last night, I released a new version of Website Grader that uses the recently released digg API.  To learn more about what was done with the digg API, check out this article:  "Will Getting Dugg on Improve Your Grades?"

5 Things I Love About The Digg API

1.  It Exists:  I can't tell you how frustrating it is to encounter otherwise savvy companies that have a great product/service that acts as a "platform" but has no API.

2.  It's Elegant:  The digg API is simple.  You invoke a URL and get XML back.  Even without writing code, you can test out the API simply by passing parameters from the URL.  The output is clean XML that you can eyeball and understand.

3.  It's Expansive:  Lots of APIs are little more than a simple interface that provides programmatic access to the data the way that users get to it.  Although this is a great start, one of the major benefits of an API is that allows creative people to use your software in ways that you may not have thought of.  Don't limit the API to just the features you can think of.  Make it deep so people can get creative.

4.  It's Immediately Available:  There's no registration and no "key" that has to be requested.  If you want to start accessing the API, you can do it now.  No muss, no fuss. 

5.  No Limits or Constraints:  Digg is not putting any limits on the use of the API (though they ask that people use their heads and not abuse it).  This is a great way to get started.  Rare is the case where you really need to put limits on the use of an API early in the game.  If it was worth developing the API, it's worth letting people loose with it.

So, if you're thinking about adding an API to your application, I'd suggest taking a look at the way digg did it.  They got a bunch of things right.

Article has 10 comments. Click To Read/Write Comments

Marketing In A Web 2.0 World: Why The Best Products Sometimes Win

Posted by Dharmesh Shah on Mon, Dec 11, 2006

Note:  This is a guest article written by Andy Singleton.  Andy is a career software professional and is one of the few people I know that can not only talk the talk, but walk the walk.  He has released several commercial products before and has lots of practical advice for others to do the same.  He is currently the president of Assembla which brings open source processes and applications to the world of enterprise software.  
Marketing In A Web 2.0 World:  Why The Best Products Sometimes Win

For 100 years, it has been a truism that “the best product doesn’t win.  The product with the best marketing wins.”  At the risk of being thrown out of capitalist society, I claim that on the Web, this is no longer true.  The best product often does win, with virtually no marketing, if it is easy to adopt.

The job of marketing was to bring prospective customers to try the product.  Marketers tell customers about the product, why they should want it, and how to get it.

However, on the Web, marketing is easy.  Too easy.  You can post a link somewhere, it’s seen globally, and potential users only need to invest one click and 30 seconds of filling out a form to become a “registered user”.  It’s easy for them.  They do it by the thousands.

If the job of bringing the customers to the door becomes trivially easy, then what is the hard part of the job?  Getting users to come back a second time is MUCH harder than it used to be.  They have so many other places to go.  It’s all equally weightless.  They click from a 24 hour work place to a global mall with thousands of options.  Adopting a Web service requires users to invest hours – hours that in most cases they don’t have.

So, in previous product cycles, marketing was the most expensive part of a launch, and the product strategy was wrapped around it.  Getting attention was the hard part.  Now, keeping attention is the hard part.  In this new product cycle, figuring out how to get users to adopt is the hard and expensive thing.  Marketing serves the adoption work by bringing in the right number of prospects for us to experiment with (in a nice way).

When I work with entrepreneurs from the old days (anybody over the age of 25), they often don’t believe me.  The good ones unfold their carefully planned marketing budgets and affiliate programs and strategic alliances.  They assume that if they can persuade the customers to try, the customers will buy.  Then they do a trivial amount of marketing – a blog post, an email newsletter ad, an email campaign, and look at the numbers.  A lot more responses than expected, with smaller conversion rates.  At that point, they understand the need to invest in the product and the initial customer experience.

Marketing can be a bad thing because it doesn’t deliver much value to the customer.  Over time, customers try to avoid paying for marketing expenses.  The biggest cost savings available to a Web startup is to cut the marketing budget.  In the old days, marketing consumed 30% to 50% of a launch budget.  That is a lot of money that can potentially be invested in product innovation and customer service.

If you can find the one feature that people will use and adopt, right way, it makes everything else easier.  So, release early and often and watch your usage dashboard.

Article has 4 comments. Click To Read/Write Comments

The Most Important Feature Missing In The Google Search API

Posted by on Thu, Oct 05, 2006

At my startup, HubSpot, we have been working with the Google Search API to implement some of the features we think would help our customers.

The Search API is reasonably robust in that it supports the various features of the Google search engine (finding related links, approximating the number of results, etc.)

But, there is one critical feature that the brainiacs at Google either forgot to include (which is bad) or intentionally left out (which is really bad).

Outside of normal “search” type stuff, I think one of the most common reasons people would use the API is to answer one simple question:

Most common question:  For a particular search phrase, where does my site rank on Google?

The reason this question is common should not be surprising (most webmasters, bloggers and SEO consultants care about this issue).  It’s also difficult to answer this question via the regular search engine (without manually entering the search term, and paging through the results looking for a “match”.  There are web utilities out there (that let you enter your API key and run a query), but they’re just doing a brute-force iteration over the result set too.

Here are some thoughts on the topic:
  1. As it stands, there is no way to answer the above simple question without making repeated calls to the Search API (basically retrieving a page at a time and checking the results until a match is found).

  1. This is even more annoying because Google only allows you to retrieve 10 result items at a time.  So, to figure out if you are in the top 100 hits for a search phrase, you have to hit Google 10 times.

  1. This is made yet more annoying because Google limits the number of calls you can make to their API to 1,000 (with no clear way of increasing this limit – even by paying money).

  1. It seems (at least from my perspective), extremely easy to implement this feature.  All they would have to do is include a separate method call that took a search query and a site name as parameters and returned the position of the first “match”.  This way, I could figure out that when searching for “software startups”, that this site ( is the #5 hit.

Given how smart the Google folks are and how common this particular need likely is, I have only two theories about why they left this feature out:
  1. Google intentionally left this feature out for some “strategic” reason.

  1. Google doesn’t realize how important this missing feature is.

For the Google API experts out there:  Am I missing something simple?  Is there a work-around to this, or have I stumbled into something that is already widely known and has already been discussed to death?  If you have insight, please leave a comment.  All help is appreciated.

Article has 10 comments. Click To Read/Write Comments

Previous Page | All Posts | Next Page