In this episode I discuss how going deeper down the technology stack can give a company an important advantage over its competitors.
NIH #26 – Unlimited online backup
A particular example of limitations of an unlimited service: Backblaze is a great service, but the way it markets itself as “unlimited online backup” is a fair bit of exaggeration.
From Backblaze site:
Unlimited Online Backup
Backblaze will automatically back up all your files including documents, photos, music and movies. Unlimited files. Unlimited file size. Unlimited speed.
I use Backblaze myself and generally recommend it to everyone. But I also recommend understanding all the limitations of the “unlimited online backup”.
Implicit and explicit limits:
- Backblaze backs up computer storage and connected external hard drives. Although you can invoke some trickery with external drives, for practical purposes the backup is limited by how much storage you can connect to your computer. In a sense this is an ideal situation for a provider of unlimited service: the natural limit exists, but it is not imposed by the vendor itself.
- Data from external drives is only kept for 30 days since Backblaze saw the drive for the last time.
- Deleted files and previous versions are kept for only 30 days. In the event of data or drive corruption you only have 30 days to recover your files , if you somehow manage to detect the problem.
With all these limitations I can hardly call it both unlimited and backup. But as I discussed in the previous episode, we simply cannot engineer things, which are truly unlimited.
NIH #25 – Infinite amount of something
We all love getting infinite amount of something for a small fee. That makes all the “unlimited” plans so popular. On practice, however, those plans fairly quickly turn out not to be unlimited, infinite or lifetime and there are reasons why.
Using “unlimited” in marketing materials has its benefits:
- it gives perception that buyer gets a lot (infinite amount that is) while paying way less than that
- it eliminates questions like “will it be enough for …?” making the purchasing decision easier
But nothing is truly unlimited or infinite:
- from the business perspective finite payment for infinite access to a certain resource or service cannot cover cost of providing that service in the long run
- from the engineering standpoint creating an illusion of infinity using finite building blocks that are in our disposal an enormous challenge. An example of that is Microsoft dropping unlimited OneDrive storage after people use it for unlimited storage
When you are offered something unlimited for a limited fee, ask yourself “where is the limit?”.
NIH #24 – Misaligned incentives
When the way company makes money is misaligned with its values, it can sooner or later lead to decisions that may turn into a disaster of some sort. Similar to what happened to Mozilla with the Looking Glass add-on for Firefox.
NIH #23 – A-a-aa not so good song
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”?
- You are finally free from the first embarrassing song on your phone
- A silent, 10-minute song is climbing the iTunes charts
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
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
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.
- “New product has feature X. I don’t need this feature. Therefore the product is bad.”
- Usually there is good reason for things they do
- Apple announces Animoji, animated emoji for iPhone X
- Let’s face reality: US Teens engage with iMessage more than any other social platform
- “Apple did not innovate enough.”
- Apple is not in the business of innovation, it is in the business of selling products
- With 60% market share selling upgrades to existing customers makes more sense than trying to convert
- High-end smartphone market share as of 2016
Not Invented Here #20 – Code does not equal project
Software projects are so much more than just writing code. It is impossible to replicate entire project with any number of lines of code.
- There is a bold claim about How I replicated an $86 million project in 57 lines of code, but the author confesses
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
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.
- Security Experts Wary as 1Password Subscriptions Push Users to Cloud-Based Vaults
- What’s new in Transmit 5?
- Adobe Hits Record Revenue of Nearly $2 Billion in a Quarter
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