NIH #23 – A-a-aa not so good song

📺 This episode on YouTube

Masking a problem without really solving it can move the problem to a more dangerous place or time. Do you remember the story about “A a a a a Very Good Song”?

Despite its popularity back in the day the song did not really solve the problem of Apple CarPlay annoyingly starting to play the very first song in the music collection, when the phone was connected to the car. It postponed that annoyance problem until 10 minutes later, when one could be driving through a busy intersection.

NIH #22 – Illusion of control

📺 This episode on YouTube

All modern systems are built out of components. Those components can come in different forms: 3rd-party proprietary, open source and developed in-house. Open source seems to be the most popular option nowadays and one may think that using open-source components is an all-around win. It is a win, but not all-around.

3rd-party proprietary

  • minimal initial effort to start getting benefits from the component: some learning curve, but no heavy lifting with development
  • all encompassing solution with features you do not need but still have to deal with
  • fairly good understanding of costs related to getting maintenance for the component over time
  • minimal control over direction of development
  • possible dead ends because of lack of transparency

DIY components

  • tightly focused solution that delivers exactly what you need
  • significant upfront costs and long and, maybe, costly further maintenance
  • with all that comes full control over the direction of development
  • draws resources and attention from the core competency

Open source

  • ready-made solution that requires minimal to start using
  • free basic maintenance by the comunity
  • solution with wide focus and sometimes “half way there” functionality
  • illusion of control induced by the fact that source can be forked and taken in-house

NIH #21 – Business of selling

📺 Watch/listen on YouTube

Common bits of criticism of new products often come from the lack of the information and the lack of desire to put them into perspective.

Casper and the middleman

Interesting observation in Recode's article about Casper:

In the booming world of online mattress sales, these reviews sites had accumulated massive power — often turning up high in Google search results for general queries like “mattress reviews” or brand-specific ones like “Casper reviews.” And without many showrooms to allow customers to try out these mattresses, online reviews carried even more weight.

Casper started with an idea to remove the middleman by selling online and allowing customers to deal directly with the manufacturer. The middleman then was the showroom. When the competitors followed Casper to the new battle ground, the Internet, and Casper was no longer the only one there, new middleman naturally appeared – the review aggregator.

Not Invented Here #20 – Code does not equal project

📺 Watch/listen on YouTube

Software projects are so much more than just writing code. It is impossible to replicate entire project with any number of lines of code.

To be fair, I have absolutely no clue what the $86M figure includes…

  • Analysis of the limitations of the technical side of the proposed solution, which likely preclude its use for building real-time system: How I failed to replicate an $86 million project in 1 line of code
  • A case for order of magnitude difference in effort depending on detailed requirements: printing a file to the console
    • Naïve implementation is 2 lines of code in Python
    • Gracefully handling printing a huge 4Gb file from USB stick, which is ejected, requires a lot more work
  • Don’t think someone is stupid. Instead try to understand why they do what they do.

Not Invented Here #19 – Full Saturation

📺 Watch/listen on YouTube

Application’s lifecycle in a marketplace explains why at times developers add features nobody really needs and why many of them try to turn their applications into services.

Lifecycle model:

  • Rapid growth on growing market
    • Revenue comes from new users
  • Few new users, but strong demand for new features
    • Revenue comes from upgrades by existing users
  • Full saturation: no new users, no demand for new features
    • New sources of revenue are needed

Atlassian acquires Trello

Atlassian has announced that it acquires Trello. TechCrunch reports:

Atlassian today announced that it has acquired project management service Trello for $425 million. The vast majority of the transaction is in cash ($360 million), with the remainder being paid out in restricted shares and options.

I think I've been using Trello in some shape or form since its inception in 2011. The product grew, but kept its original spirt and idea. And now it has grew to almost half a billion dollars.

Atlassian suggests it will continue development of Trello. The immediate plans are outlined in Atlassian's press-release:

In addition to launching a new version of its existing Trello integration for HipChat, Atlassian will be launching Trello integrations for its other leading collaboration products, including JIRA Software, Confluence and Bitbucket. The integrations will be available in the Atlassian Marketplace, which is one of the largest enterprise software marketplaces in the world along with Amazon's AWS Marketplace and Salesforce.com's AppExchange.

Integrations are good and are a natural thing to happen after such acquisitions. Would be very interesting to see how Trello will change little details.

EasilyDo Mail – speedy new mail app

As I expected, new email apps do not stop coming. This time new app from EasilyDo

In addition, the new EasilyDo Mail app offers several unique features aimed at differentiating its app from other alternative mail clients on iOS, including tools to detect and prevent email tracking, ways to quickly unsubscribe from newsletters and automated mailings, email snoozing, and faster search, to name a few.

Many of other email clients have many of mentioned, so I'm not sure how much differentiation that would be. 

Not the last email client

This past New Year season was special in many regards. Yet, one thing in particular stood out: a number of new email clients entered the scene and a number of older ones changed dresses to keep up with the play.

In these recent times we've got (in order of appearance):

In the nearest future we expect to get at least new Spark for Mac.

For a crowded and low-margin market like email clients and email services market that's a lot. The increased interest to sending and receiving emails with taste can be attributed to now officially documented death of Mailbox, to reignited conversations around privacy of communication, and partially to decay of current market leaders. Developers could not miss the chance to fill the void of email innovation. But as this wave of enthusiasm washes out will there be anything interesting after that? Have we seen the last major email client?

I argue not. Email is based on a protocols created more than 30 years ago. It became so universal and ubiquitous that there will always be something that could be done better for some of the various emailing use cases. And developers will always try to fill those bubbles of void that regularly appear in different places of the email universe.

Every platform has to have an email client. Each vendor provides one as a part of platform's standard offering. The standard email client has to be capable, but it can not be remarkable, it can not alienate users. It has to serve diverse audience of platform users. By the virtue of this fact developers of platform apps can not take bold moves in user experience design. And they have little incentive for providing beyond-standard functionality. Standard email clients are usually the best in integration with their mother platform. Yet they leave enough of features to be desired and let other apps try to address them.

After all these years we use email as a communication vehicle in every possible way. We talk to one another (although admittedly more rarely via email these days). We get notifications from services. We share files. We receive information in newsletters. We use email as a common denominator of electronic communication, when other channels can fail. This naturally creates the world, where someone who never received a newsletter cannot appreciate Spark's ability to add link to Instapaper or Pocket in one click, or someone who is used to quickly sorting through his inbox with gestures in Mailbox is not a big fan of GMail app. Different email apps excel in different areas and have their own fandom.

There is another outcome from the email being with us for such a long time. Developers tried almost every way to squeeze every last penny off the market. Sparrow was the first to show that an email app alone cannot sustain its own development and support. Mailbox has shown that subsidizing mail app development with other sources of revenue does not always work. Email apps market has scale – [almost] everybody needs a way to send and receive emails – but has to bring money from elsewhere to be sustainable. Many have tried and many will try to solve this conundrum to give us the last email client we will ever need.

Figuring out business model for an email app is important. Email apps are complex. Even bare minimum of features requires a lot of things: support for GMail, implementation of IMAP, some sort of contacts management, decent performance for dealing with our multi-gigabyte mailboxes, and more. All this makes developing new world's best email app a costly endeavor with uncertain financial outcomes. And, as if that was not enough, we have to take into account that most modern email clients can not function without a backend of their own. If app manages to get to any meaningful scale, operational costs of keeping the lights on for the app will be really high.

All that said, developers are creative people. Some of them are risky and brave. And although we are now in a period of relative calm in email client news, I believe we have not seen the last greatest email client to rule them all.