There are no x10 developers, but there are certainly 1/10 ones

I keep seeing the term “x10 developer” pop up recently, and I think it’s misleading and leads to a rock-star / primadonna culture that benefits no one.

“x10 developers” are, in fact, proficient developers, who are experienced with their stack and problem domain. Once you get to this point, you can still find room to optimize – some people are inherently more focused or talented and you can always gain more experience, but the difference between developers who are proficient at what they do will never be a x10 multiplier – it will be closer to a variation of 30-40% in productivity. In some extreme cases (super experienced, focused, and naturally gifted), you might even reach x2 times productivity over a baseline proficient developer (I’ve seen it in action).

On the other hand, you have developers who are simply not proficient. They either have no aptitude for programming at all, or are so inexperienced that progress is very slow as they are learning everything as they go. Those are the “1/10 developers” and they make proficient developers (i.e, professionals) seem like x10 developers.
Continue reading There are no x10 developers, but there are certainly 1/10 ones

The Real Cost of Software Development

In a previous lifetime (until about 3 years ago), I was working at a software development firm as part of a small webdev-shop team of 3. Our focus was building MVPs for aspiring entrepreneurs, file guiding them through specifications, user-experience, product decisions and marketing (we called it “concept-to-launch”).

Coming across a heated discussion a couple of days ago on Hackernews over an article titled “30 pounds in 30 days”, took me back to the time we were educating clients on the cost of software development. I would like to offer my perspective on outsourcing, cultural difference and the overall cost of outsourcing software product development.

(For the short summary, skip to the TL;DR below)

Continue reading The Real Cost of Software Development

Solving the wrong problems

As a power user and an entrepreneur (not to mention a developer), I often look at a software product or service and think how I would’ve done it differently. If the concept is interesting enough, I might dive into some initial research to understand the market and the needs of the target audience.

Most often the process stops at that point as I realize that –

  • The product is not as simple as it seems on the surface,
  • There are reasons it is built the way it is, which were not immediately apparent,
  • There is already strong competition in that space

I went through a similar progression when I came up with the idea for my startup, Binpress. I had just finished yet another client project rather quickly, thanks for the most part to the mature code-base I’ve been building for several projects up to that point. I was thinking to myself – instead of continuing to provide custom development for one project at a time, wouldn’t it be more efficient to just license the code stack I’ve been using as reusable components?

That was the initial idea, anyway. From there it grew to an idea of building a marketplace for developers to do the same, with the major competition at the time being codecanyon. The reason I felt codecanyon were “doing it wrong”, is that they focused on low-end, low-cost components mainly for designers and beginning developers, without any kind of quality control. They did seem to be making significant revenue (I scraped all their sales data and I can say with confidence it is significant).

Understand first, build later

Alright, so why am I bringing this up now, and how does it relate to the title of the post?

The research process I went through when I decided to build Binpress took close to a month. I used codecanyon for a while as a publisher and sought out additional similar services. I talked with freelance developers looking for internet jobs and codecanyon sellers, gathering as much insight as I could. The goal was to understand why codecanyon was built the way it is, and if my take on it is valid.

Not everyone shares the same process – I just read a blog post on a new service called Gitiosk, which is termed “Building a Binpress challenger in 48 hours“. In it, the team explains why they think it is better than Binpress –

  • It is not a marketplace
  • They don’t do any marketing for you
  • No review process or quality control
  • You basically sell your code yourself

Basically, they looked at all the main value points of  Binpress and decided they are expendable. As someone noted in a HN thread on the blog post, the value offered by such services is everything but the actual sale. There is marketing and reach, which is difficult for everyone and developers especially suck at it, there is licensing which is difficult and confusing and you better have some legal authority, there are conversion and trust issues with prospective clients, if your code component costs something significant (we have components on Binpress that sell up to 1500$), or even if it costs at all – don’t underestimate the barrier of getting someone to hand over his credit-card details online.

We solved all of those problems (through a long, iterative process), and despite the opinion of the commentator on HN, we did take off – since the value of quality, ready-to-use code is not zero as he suggests (a surprising viewpoint). Gitiosk looked at the same market and decided to solve a very different problem. In my opinion, as someone with close to 2 years of experience with this market, they solved the wrong problems – and it’s probably only because they didn’t understand it enough.

On the bright side, it did take only 48 hours for a team of 4, so no major time loss there. Time will tell if their approach is better than ours (though I feel we already made our point, with many developers making a living from being Binpress publishers).

 

Suggestion to Twitter: Here’s how you monetize without ruining your ecosystem

As you probably heard, Twitter recently tightened the noose around API developers with new limits and restrictions. Twitter is possibly the biggest public API provider today, with 13 billion API calls a day in 2011. This makes sense if you’re Twitter, and are trying to increase your revenue from ad sales – you need people on your site, consuming those ads, not using API apps to consume their feed indirectly. At the same time, they reduce their biggest cost – supporting their API infrastructure. This is one thing which I could never see happening with Youtube as most of the people who make money off of Youtube, monetize their videos to earn money and without the support of companies like The Marketing Heaven who guarantee increased number of views, the concept of money making through Youtube would just be a faded concept incapable of being successful when implemented. Recently, I was buffled to discover that most users just buy youtube views from companies like this and at first I was quite confused, but it later made sense cause with thousands of daily videos being uploaded on it people will have to try different methods of marketing their videos to make them stand aside from the general lot.

If I were Twitter, I’d go about it a different way – why put hard limits when you can just add tax instead? charge a small amount for every API request over the limit (or sell bulk packages) – suddenly you have a major revenue stream, and API developers still get a chance to scale using your API.

Soft cap vs. Hard cap

If you’re into sports, this is somewhat similar to the difference between the salary cap system implemented in the NFL vs. the one implemented in the NBA. The NFL has a hard cap, which means teams have to stay under a specific total number for player salaries at all times. The NBA on the other hand, has a soft cap, which allows teams to exceed the cap number by paying increasingly larger tax for every dollar spent over the cap.

Both of those cap system exist as an attempt to create competitive parity in those leagues, by preventing teams from bigger markets outspending teams from smaller markets. Each has its own merits in the context of sports competitiveness, but in Twitter’s case there is no reason for a hard cap at all. What does Twitter gain by putting a hard limit on API usage?

Continue reading Suggestion to Twitter: Here’s how you monetize without ruining your ecosystem

Developers vs. Bigcorp

With all the rage recently on Twitter’s changes to their API and how it affects developers and their apps who rely on it, it’s easy to forget that Twitter is hardly the first major tech company to take such an approach to lifeblood of its ecosystem.

Yes, most of the large tech companies today are taking a hardline approach when dealing with developers who use their platform, treating them with entitlement as they hand down “our-way-or-the-highway” rules and regulations that leave little recourse when things go wrong.

Continue reading Developers vs. Bigcorp