Tag Archives: software engineering


This blog is turning out to be about a lot about ‘firsts’ — first launch, first project to get X users, etc. To continue this fine tradition, here is another first.

Remember LinkPeelr, a weekend project that grew to 3,000 users when it was featured on lifehacker.com? The code for LinkPeelr has been on github from the very beginning, and just when I thought the interest in this tool was subsiding someone submitted a patch that fixed the way tooltip rendering conflicted with native tooltips on Twitter.

How cool is that? Someone actually took the time make the changes and create a pull request in github. Considering that the  project is tiny it would far easier to clone, modify the local copy to your heart’s content, and move on without me noticing anything (other than a fork).

Except that it wouldn’t work because it wouldn’t have the LinkPeelr presence online, another Chrome extension would have to be registered, and so on. In short, someone would need to be really determined to go off and “deep copy” it.

And I suppose there isn’t enough commercial value in LinkPeelr (there isn’t any, in fact) to want to copy it. This being said, there are clearly people for whom this project represents enough value to be improved further through contribution rather than cloning. I feel that’s a fundamental and important distinction because contribution expresses a commitment to public good whereas cloning does not, at least not necessarily.

So what does that leave us with? There isn’t enough value to invite malicious intent, and just enough value to invite the good will of collaboration. A wondrous amount of value indeed, and if you are in this range, you are what I would call patchworthy.

This tiny speck of a contribution also disproves the opinion (not that we don’t have sufficient evidence to disprove it already) that putting your work in public domain will necessarily invite plagiarism or that sharing your startup ideas is akin to writing someone a check for the sum of your unborn company’s valuation.

In the end I am definitely happy that someone else cares this much about LinkPeelr. I see it as a good omen, and I will be releasing an update with the contributed changes soon. :)


Product Management and “The Other White Meat”

Let’s start with a Wikipedia definition:

Typically, “pork” involves funding for government programs whose economic or service benefits are concentrated in a particular area but whose costs are spread among all taxpayers.

This week (for my day job) I attended a recurring gathering of companies meeting to decide what the next low-power wireless standard is going to be like. The subject of this post has nothing in particular to do with professional conferences or low-power wireless standards. You can go through the exercise and replace ‘companies’ with ‘stakeholders’  and ‘low-power wireless standard’ with ‘feature set’. In fact I want you to go through the exercise since it’s unlikely that low power wireless is of any relevance to you.

The highlight of this gathering was an intense debate about the choice of a particular component. Several alternatives were offered and dissected in nauseating detail. In the end the majority seemed to coalesce around one of the choices. In fact when the vote was taken more than 3/4 of all participants voted for it.  That choice was then committed as a mandatory requirement, i.e. any product implementing the spec would have to implement this particular component.

I would expect that to be the end of it. However, what happened next was that one of the companies suggested that the runner up, which only 1/4 of the companies voted for in the first round, should also be entered in the spec as an optional requirement, i.e. a product implementing the spec could implement the other component, while still implementing the mandatory one.

The argument offered in defense of this addition was that the company had a large customer who insisted on the runner up option, and although said company would have preferred for it to be mandatory, they wouldn’t mind implementing both if they have to. Remarkably a lot of attendees found this line of reasoning convincing and proceeded to vote for adding the second choice as an optional requirement. After all, they already got what they wanted.

The fools! What nobody seemed to notice was the by bloating the spec with optional components that nobody by a few companies cared about, everyone was footing the bill.

Product architecture

Why do I think this seemingly harmless addition qualifies as pork?

  • Bigger spec means bigger test plan and more resources required by all vendors during verification and certification of their products. Likewise, interaction of optional and mandatory features often leads to subtle bugs, increased complexity and everything that follows.
  • We are talking about a wireless protocol spec so optional features tend to affect even those products that don’t implement them because everyone has to at least be aware of all the options.  Ironically enough, one of the most important criteria for the original choice was its small code size, so the optional feature actually devalues the mandatory one.
  • By voting for to make the runner up an option, all vendors effectively assumed the responsibility of  explaining to their customers why their product does not implement it all. The majority has done itself a disservice by automatically putting itself on the defensive.

A product manager’s job is rife with this kind of minority-staged shenanigans. The boss wants to turn all yellow buttons into green ones. A vociferous user wants an arcane API hook. Engineers want it in Ruby. The compromises that we succumb to today may seem innocent enough, but that’s only because we thought about them for the whole of 5 seconds or while still intoxicated with our previous wins. And so on our watch and with our own timid approval, the spec, the requirements document, the backlog, whatever it may be at your organization, starts to get weighted down with pork.

As product managers our job is to optimize the resources to build the greatest possible value for the product that eventually hits the market. In light of this, it’s a no-brainer that every piece of pork should be viewed with extreme caution and as a possible threat to our most important function.

Letting down our guard and giving pork a free passage means that we too sign up to foot somebody else’s bill.

Some thoughts on API use and design


All software is building blocks. Exceptionally good software is constructed from orthogonal pieces that fit together like they belong nowhere else, are interchangeable and make the overall structure only marginally more complicated than the components from which it is built. The “seams” or the interfaces between the blocks are the APIs, and it is here, I claim, that most engineering magic happens.

In my experience API design is extremely labor intensive, generally under-appreciated, hard to learn and harder still to teach. The design is almost never right the first time around (or the second time around, for that matter), yet the difference between good APIs and bad ones can be appreciated by looking at software structures that given API makes possible. To give you another analogy from architecture, bad APIs give us shacks cobbled together and teetering on the verge of collapse and good APIs give us Notre Dame cathedrals.

Increasingly software design is all about combining of-the-shelf components into a coherent whole. I’ve noticed it in my day job and while working on JustLiked. The amount of software packages freely available on the internet is staggering and each comes with its own API. In the end we do less in-house API design and more gluing. And every time we need to glue something together, we are faced with the question of what and how to glue.

I think the temptation to reinvent the wheel is huge, so the answer to the question of what and how to glue is often “let’s roll our own”. I don’t mean we are just tempted to write more software–we are tempted to write software which is designed for more reuse than it will ever see. The latter tendency preempts the process of selecting from available  components with designing our own with its own API. I’ve fallen into this trap myself recently, and all I have to say is:

Don’t reinvent the wheel, instead trust the API you are given.

In my view it’s much better to err on the side of more glue than designing a new self-contained, interchangeable building block to fill the void. The more “exposed” and “universal” you want to make these new building blocks and their APIs the less likely you are to succeed on time and on budget. It’s my subjective opinion, but it’s served me well over the years.

Once you find the component you need, use it in the way that it was intended to be used. Every technology has its sweet spot where it shines, so let it shine. Even if you can’t find something that fits perfectly, don’t kludge together a brand new component with its marginally better API because there are hidden dimensions, the secret sauce of API design that you haven’t mastered yet and it will come back and mercilessly haunt you way past your project deadline.

And even when you know what you are doing, make sure that what you are about to do actually gets you any closer to a business objective. Chances are it doesn’t, unless of course you are building an SDK.