Ethereal Bits - Tyson Trautmann's musings on software, continuous delivery, management, & life.

Universities Are Alive & Well

February 18, 2019 by Tyson Trautmann Leave a Comment

The impending demise of the university has been greatly overstated.

Since the launch of the first massive open online course (MOOC) back in 2006, a vocal group of university-dislikers have taken to social media aggressively to declare the university model obsolete and dead. The latest round of vitriol was seemingly spurred when Lambda School, a trade school that teaches coding to students online and uses an income sharing agreement in lieu of tuition, announced that they closed a $30M Series B funding round. University naysayers see new alternatives like Lambda School as attractive drop-in replacements for an outdated higher educational model.

Meanwhile, the data suggests that universities are alive and well, with most meaningful metrics moving up and to the right. Detractors rip the increasing toll of loans on graduates; a recent report from the Institute for College Access and Success claims that the average graduate takes on $28k in debt to attend school. But figures from a survey conducted by the Bureau of Labor Statistics show that attaining a university degree increases average annual earnings from $35k to $59k, dwarfing the cost of loan payments and showing that the broad financial value proposition of higher education is extremely attractive. Student demand for universities continues to skyrocket, particularly at top-tier schools. For example, the University of California Berkeley received 108k applications for admission in 2018, up 120% from the 49k that the university received in 2009. Demand from employers for graduates of top universities is also high. PayScale data shows that the average mid-career salary for a Stanford graduate grew from $112k in 2012 to $157k in 2018, an increase of 40% in just 6 years.

If students are turning out in record numbers to attend universities and the job market continues to place increasing value on a diploma from a high-caliber institution, why are people so quick to hate on schools and look for a new model? There are several good reasons. The first is that the current model is hitting scaling limits. 207M students around the globe are currently studying at higher-education institutions according to a paper published by UNESCO, but that’s still a relatively small fraction of the total population of 1B people between the ages of 16-24 and it would take decades to increase capacity by 2-4x with the current model. The College Board reports that the 10-year average tuition cost increase is roughly 5% per year, which is well ahead of inflation and will continue to make it even harder to make higher education accessible in poor areas. The second reason to challenge the current model is that it negatively impacts upward mobility by providing a disproportionately large opportunity for people from wealthy families. A report released by Opportunity Insights last year showed that 38 universities, including 5 of the 8 Ivy League schools, admitted more students from families in the top 1% of the income scale (families that earned more than $650k per year) than students from families in the bottom 60% (families that made under $60k per year).

Software scales infinitely, so it’s not surprising that people have embraced software platforms like MOOCs and software-powered coding boot camps as a means to make education scalable, provide access to all, and increase upward mobility. The problem is that current offerings like Lambda School that are being touted as university replacements are only offering a subset of what universities provide. The caliber of schools obviously varies wildly, but a good university offers students the following:

Courses that provide deep knowledge in a subject of specialization. This includes the theory behind a subject, not just the practical. The theory is important because it provides a platform to understand the state of the art as practices evolve.
Courses that provide broad knowledge in other subjects. Most innovation is going on at the intersection of multiple domains (eg. computer science and biology, cryptography and game theory) and jobs that are further from the bleeding edge will be earlier targets for automation. A general understanding of math, science, philosophy, ethics, and other subjects is more important than ever.
An environment that encourages learning, innovation, and launching new ideas. There’s an unparalleled sense of energy that comes from dropping a group smart and ambitious students from multidisciplinary backgrounds into the same physical space. It’s not a coincidence that so many companies are founded on university campuses.
A strong and diverse network. It’s impossible to overstate the importance of a strong network in business, and universities provide a unique channel to connect with fellow students and alumni to build a network.
A credential. Achieving a degree from a university means that with some probability, the credential holder can work hard, is intellectually curious, can work in a team, and has achieved at least a base level of the kind of broad/deep knowledge mentioned above.

At best, current university competitors are offering bits of #1 (focused on practical knowledge, not theory) and a less valuable version of #5. That doesn’t mean that those competitors won’t ultimately be successful in disrupting universities over the long term. Lambda School is currently following Clayton Christensen’s disruption theory formula by serving customers at the low end of the market (students that don’t want to pay up front for tuition, so universities don’t want them) in a way that is “good enough”. But the combination of technical differentiation through software distribution and business model innovation through different payment models won’t be enough for those companies to go upstream into the broader market until they start thinking about the value proposition of universities more broadly and looking for creative ways to deliver on #1-5 above.

As a fan of both universities and Lambda School, I hope this happens because competition will ultimately result in a better product. We should all be cheering for innovation that increases access to education and levels the playing field for students. But the people that are proclaiming that universities are dead have jumped the gun.

Finding Metronomes

February 10, 2019 by Tyson Trautmann Leave a Comment

Alberto Salazar is track coach and a former world-class runner who has held several American track records and has won both the New York City Marathon and the Boston Marathon. As a coach, Salazar looks for ways to blend the best practices in sprinting with those in distance running. One of his pieces of coaching advice for distance runners is to practice maintaining a high cadence (ideally close to 180 footfalls per minute) by running with an electronic metronome.

I read Salazar’s advice in an article and decided to give metronome running a try. As an amateur runner with a long natural stride, I’ve historically run with a low cadence that gets even lower towards the end of a run as I get tired. I assumed that my first couple of runs with a metronome would be slower while my body adjusted to a shorter stride and a quicker cadence, but the opposite was true; I ended up running some of my fastest times for the respective distances that I ran.

As I thought about the reasons for my improvement, it struck me that shortening my stride and improving my mechanics wasn’t the only benefit that I was getting from the metronome. The metronome was also simplifying the decision to keep my pace up. When I run without a metronome and I start getting tired, I’m faced with the frequent decision of whether to slow my pace to account for fatigue and, if so, how much to adjust my pace by. When I run with the metronome, I only infrequently need to decide that I’m going to continue to follow the metronome. In essence, the cognitive load of deciding how fast to run is reduced from high to low by turning a frequent continuous decision to an infrequent discrete one.

This is an incredibly powerful concept that isn’t limited to running. Changing behavior takes a massive amount of cognitive effort. In my experience, change is more likely to be successful if you look for “metronomes” that can reduce cognitive load than if you try to just brute force the change. Amazon CEO Jeff Bezos describes this phenomenon in his famous quote that “good intentions don’t work, but mechanisms do.” Mechanisms like Salazar’s metronome reduce the cognitive load of constantly trying to follow a good intention and increase the odds of success.

To think about how this plays out in the real world, consider an example: one of my New Year’s resolutions is to improve mental health by spending less time on my phone. I’ve put several “metronomes” in place to increase my odds of achieving the resolution. For example, I’m blocking out time on my calendar and using a Pomodoro timer app to restrict access to my phone for several hours in the evening while I hang out with my kids, read, meditate, and get ready for bed. My wife and I also just planned our first quarterly phone-free getaway weekend for our family as a means to recharge and reprogram our brains. It’s early, but I’m already seeing these mechanisms beginning to drive positive change that wouldn’t be taking place otherwise.

What behavior are you trying to change right now and how could a metronome help?

Move Fast, in the Right Direction

January 30, 2019 by Tyson Trautmann Leave a Comment

Moving fast is great, but it doesn’t do you any good if you’re moving in the wrong direction.

Zack Kanter recently penned an article for TechCrunch where he made the case for startups to adopt a Serverless-first approach to increase software development velocity. “If the fastest startup in a given market is going to win” says Kanter, “then the most important thing is to maintain or increase development velocity over time.” He’s absolutely right. If a billion-dollar market exists, both other startups and incumbents in that market (or in adjacent markets) are going to compete for that market and velocity is going to play a large role in determining who wins, and going Serverless will increase long-term velocity.

But there’s another most important thing. As Martin Fowler wrote several years ago, “the biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is.” The best way for startups to build fast feedback loops, validate new ideas, avoid shipping things that aren’t useful, and to stay pointed in the right direction is to adopt Continuous Delivery.

Continuous Delivery (CD) is the capability to get any software change into production quickly, safely, and in a sustainable way. In practice, it is achieved by automating entire the process of taking a code change to production, which typically includes building the change, testing the change, deploying the change to pre-production environments for further integration testing, and then finally having an option to deploy the change to production environments. Most modern tools for automating the release process describe the automation as a pipeline that new software revisions flow through. As Fowler points out, companies that are able to maintain CD over time prioritize maintaining working delivery pipelines over new feature development.

The Continuous Delivery landscape is riddled with domain specific jargon that can be confusing for people who are approaching the space for the first time, so it’s worth taking the time to understand a few related concepts. Continuous Integration (CI) is the practice of merging code back from development branches into a shared branch often, which requires thorough and reliable tests as well as investment in build and test infrastructure so that tests can be run against any change to validate that the change can be safely merged. Some people describe CI as being upstream from CD in the development and release process (which is where the term CI/CD comes from), but given the above definitions, it makes more sense to view CI as the early part of the CD process because it plays a vital role in empowering an organization to ship any change. Continuous Deployment is the process of actually releasing every change to production. You need Continuous Delivery to Continuously Deploy, but the reverse is not true.

None of these ideas are new. Kent Beck coined the term Continuous Integration twenty years ago as part of the Extreme Programming movement, Timothy Fitz first blogged about Continuous Deployment in 2008, and Jez Humble and Dave Farley published the first book on Continuous Delivery in 2010. So why is CD a big deal for startups right now?

In their book Accelerate, Humble, Nicole Forsgren, and Gene Kim reveal their findings from several years of research about the way that teams ship software. Their flagship finding is that high performing teams achieve higher levels of throughput, stability, and quality without trading those attributes off against one another. More specifically, high performing teams deploy small batches of software changes to production frequently, which results in a lower percentage of changes failing, quicker resolution when changes do cause failures, and lower lead time to go from a customer making a feature request to shipping the requested feature. Perhaps most importantly, CD also lets these teams test the features that they’re shipping frequently so that they can validate them with customers and course correct if the features aren’t meeting a real customer need.

Despite these benefits, CD is still under practiced, particularly at small companies and startups. A recent study conducted by DigitalOcean found that 52.1% of respondents at companies with more 1000 employees reported using CD, but just 45.7% of respondents at companies with 6-25 people and 35.3% of respondents at companies with 1-5 people are using CD. If startups win by moving quickly in the right direction, there is no reason for any software startup to launch without embracing CD on day one. The process of manually shepherding a dozen changes to production likely costs more than the initial investment necessary to automate the release and adopt CD.

The number of tools available for customers to use to adopt CD and automate their release process is growing rapidly. For companies that deploy their infrastructure to Amazon Web Services, AWS CodePipeline lets customers automate their release process from hosted source code repositories like AWS CodeCommit or Github all the way to deployed services running on AWS EC2, ECS, Lambda, or other AWS environments. Google’s CloudBuild allows customers to create pipelines that use built-in integrations to deploy to Kubernetes Engine, App Engine, Cloud Functions, or other GCP environments. Microsoft’s Azure DevOps product includes Azure Pipelines, which can automate releases not only to Microsoft offerings like Azure VMs and Container Service, but also to other cloud providers. Elsewhere in the cloud ecosystem, products like Jenkins, Travis, CircleCI, and GitLab are all popular solutions for automating the release process. Microsoft’s $7.5B acquisition of Github has caused a fresh wave of excitement about the developer tools ecosystem from early-stage investors, which is fueling a new wave of exciting startups that are pushing the CD frontier forward while driving down costs.

Further, CD is eating the entire stack, which is opening up new potential benefits for adopters. The rise of Infrastructure as Code (IaC), provisioning resources up and down the entire software and hardware stack through software instead of a manual process, has made it possible to apply the principles of CD to the entire stack. Companies that leverage IaC offerings like HashiCorp’s Terraform or AWS CloudFormation can take advantage of the CD products listed above to deploy low-level compute and storage resources continuously in the same way as software. Need to spin up capacity in a new Virtual Private Cloud in a different region to add redundancy and reduce latency? Push a template change through your infrastructure pipeline and the new resources will be provisioned for you with the same kinds of testing and blast radius mitigation that you’re using to getting from a software pipeline.

Every startup is ultimately a factory that takes time and capital as an input and produces a product or service as an output. The company that wins in any given market is determined by who reaches product/market fit first. First-mover advantage only goes so far; battles are ultimately won by maximizing velocity and building tight feedback loops to stay pointed in the right direction, and Continuous Delivery one of the very best available tools to achieve that outcome.

Scrum, Control Planes, and Data Planes

January 17, 2019 by Tyson Trautmann Leave a Comment

It’s not uncommon see tweets bouncing around the twittersphere describing how agile methodologies for software development are bad because of [insert problem here] and can be fixed by [insert solution here]. This week, a tweet by Ryan Singer caught my eye:

“Been talking to CTOs and Product Managers about their processes. Themes: low morale among engineers and the feeling they aren’t making meaningful changes to the product. Two-week sprints, Scrum and JIRA contribute to a high-overhead, low-productivity culture of micromanagement.”

Ryan correctly identifies an issue that every engineering manager needs to be cognizant of: engineers need to feel like they are making meaningful changes to the product or team morale will be low. In my opinion, however, his proposed solution misses the mark. In a subsequent tweet, he suggests that teams adopt longer sprints where engineers are free to define tasks and implement them how they see fit within a sprint. He’s proposing a Data Plane fix for a Control Plane issue.

In the world of routing, the Control Plane manages the rules and configuration of the system, including the current known network topology and other information necessary to route packets. The Data Plane forwards packets based on the information that has been provided by the Control Plane. The Data Plane is essentially the execution engine, while the Control Plane is providing the rules with which to execute. The Control Plane and Data Plane operate in separate threads and have very different traffic profiles. The number of requests to the Control Plane is relatively few, so handling requests can take orders of magnitude longer, but it’s important that every request is received and handled correctly. The Data Plane, on the other hand, is typically flooded with requests that must be handled quickly, but it’s less critical that every request is forwarded optimally because errors can often be handled downstream. The integration point between planes is typically the Routing Information Base (RIB), which is written to by the Control Plane and read from by the Data Plane.

In Scrum, the Control Plane is the work that is traditionally done by a Product Owner to generate the Product Backlog as well as some of the work that is typically handled by a Scrum Master to define the parameters under which the process operates (sprint duration, ritual details, etc.). The Data Plane includes all of the rest of the work that is done by the Scrum Master and the Development Team to pull work from the Product Backlog into the Sprint Backlog and execute on that body of work. Like routing, the Control Plane and Data Plane operate on separate logical “threads”; a different cast of characters is usually involved in the decisions made on each plane, and the cadence of delivery is different (eg. writing to the Product Backlog does not follow the Sprint cycle). The integration points between Scrum planes are the the Sprint Planning process, where work is pulled from the Product Backlog into the Sprint Backlog (the equivalent of the routing Data Plane reading from the RIB), and the Sprint Retrospective process, where feedback logically flows back into the Control Plane and can be used by the Scrum Master to change the parameters of the Scrum process.

Based on the context, Ryan’s statement that engineers aren’t “making meaningful changes to the product” could mean one or more of the following:

So much time is being spent on Scrum rituals that engineers have no time to engineer.
Project management tools like JIRA take so much time to use that engineers have no time to engineer.
Engineers have no mechanism to give input into the Product Backlog; the Product Owner is dictating product changes without taking feedback and the Scrum Master is also being over prescriptive about implementation details.

#1 and #2 are Data Plane issues that I have trouble buying. On teams where I’ve run 2-week sprints, I’ve typically held a two hour Sprint Planning meeting, one hour Sprint Review meeting, one hour Sprint Retrospective, and fifteen minute daily Stand-up meetings. That means that <10% of our Sprint time was spent in team rituals. In my experience, the time necessary to keep task status up to date in JIRA or another project management tool once the Sprint has been planned is also trivial in comparison to the amount of time available in a Sprint. I’m not against making Data Plane optimizations to these processes, but there isn’t much to be gained.

#3 is a Control Plane issue that I have seen many times, but it cannot be adquetely solved by changes to the Data Plane. Engineers care deeply about the products that they work on and have unique insight into the details of the product and how it is implemented. It’s critical to inject engineers into the Control Plane by building mechanisms that give them a seat at the Product Owner table. On my team at Amazon, we do this a number of ways, including engaging engineers in our Working Backwards process (eg. having them assist in writing PR/FAQ docs for new features that we’re considering) and by including then in roadmap planning exercises as a key stakeholders and contributors.

If you want to boost team morale, avoid micromanagement, and ensure that team members can meaningfully impact the product, plug engineers into the product planning process instead trying to hack product planning into the middle of a Sprint.

On Teams & Problem Spaces

March 3, 2018 by Tyson Trautmann 6 Comments

Teams are most effective when they are organized around problem spaces and are explicitly named after the problem space that they’re solving. Unfortunately, if my experience is representative, this isn’t the norm. If I think back on the organizations that I’ve been a part of as an individual contributor or inherited as a manager at Microsoft, Amazon, and Riot, I’ve frequently seen teams organized around products, solution spaces, and code names. To explain each option, consider a fictitious team with the following properties:

The team is part of a larger organization that builds tools for feature teams to deploy, operate, and scale backend services on the company’s private cloud.

The team previously decided that its mission is “to make it easier for feature teams to operate deployed services” and its vision is that “services are highly available and easily scalable with virtually no operator intervention”.

The team’s current flagship product is an alerting and monitoring system called Brometheus.
The team happens to be obsessed with Star Wars (who isn’t?).

Now suppose you’re tasked with naming the team. You could name the team the Brometheus Team after it’s most important product. Alternatively, you call them the Monitoring Team, since the solutions that they currently own are in the monitoring space. You could accept the suggestion of a couple of team members that believe that names don’t matter and have pushed to be called the Jedi Order. Or, you could name the team after the broader problem space and call it the Operability Team.

The final option is superior to the other options for several reasons:

Unlike the product and solution space options, it doesn’t constrain thinking and imply a particular solution. If you’re the Brometheus Team, your work will always revolve around improving that product (you have a hammer and everything will look like nails). Similarly, the Monitoring Team will always focus on building monitoring products. The Operability Team is free to decide that they can make it easier to operate services by working on auto-scaling, service call-tracing, or debuggability instead.
Unlike the code name option, it’s immediately obvious what your team does and what sandbox you play in. The Jedi Order may sound cute and the team may rally around that identity in the short term, but at scale, it becomes difficult for customers to keep a mental map of who is working on what. Further, the team’s new identity is not rooted in being a team and not the problem they’re solving; the former tends to fizzle much more quickly.

Reorganizing or renaming teams can be hard work, particularly if the team’s current identity is tightly wound around their current name or organizational structure. But in the long run, doing the work to identify problem spaces, organize teams around those problem spaces, and to explicitly name teams after the problem space they’re tackling is worth it.

On Cryptocurrency, Blockchain, & Cloud Computing

December 7, 2017 by Tyson Trautmann 1 Comment

With Bitcoin’s price soaring, I’ve found myself spending a lot of cycles explaining why I’m still bullish on cryptocurrency and blockchain. I’ve also found myself in a number of conversations where I’m trying to convince friends that most of the talking heads from the financial world fundamentally don’t understand what blockchain is about or how it will change the game. This post is my attempt to channel those discussions and dispel several popular myths that are currently making the rounds on the Twittersphere. Along the way, I’m also going to try to convince you that the blockchain not only has the potential to revolutionize the financial world but is also poised to have a massive impact on cloud computing. Without further ado, let’s dive into some background on both computing and blockchain.

Blockchain as a Cloud Computer

Every computer can be broken down into two fundamental components: compute and storage. When you use your computer to multiply two numbers together, your computer loads (compute) values from memory or disk (storage) into registers (storage), adds (compute) the values together, and stores (compute) the result in another register (storage) where it can then be stored (compute) in memory or on disk (storage). From web surfing to spreadsheet-crunching to gaming, all computer applications boil down to computation that manipulates stored values in interesting ways.

Cloud computing is no different. Amazon Web Services, the leader in hosted public cloud, offers tens (if not hundreds) of unique services that can all be broken down into compute and storage that runs on Amazon’s massive infrastructure footprint. For example, AWS CodeBuild allows software developers to build and test their code in the cloud and then store the built artifacts in a data store like Amazon’s Simple Storage Service (S3). Like most of its services, Amazon bases the pricing for CodeBuild and S3 on the number of minutes that the underlying virtual machine uses (compute) and the number of terabytes used per month (storage) because the company understands that most of its value-add can be decomposed into compute and storage. AWS made $4.6B in revenue in Q3 of 2017 alone which represents a massive year-over-year revenue growth of 42%, so the global market for cloud computing products is clearly vibrant and growing quickly.

The simplest way to think about a blockchain is a big, distributed cloud computer that no single person, company, or government controls. Individuals called miners connect their computers to the blockchain so that they can be used to process transactions (compute) and write the results of those transactions to a digital ledger (storage). The mechanics of executing transactions depend on the blockchain implementation and are typically heavily rooted in cryptography, but in a proof-of-work system like Bitcoin, each mining node is taking a block of transactions and hashing them (compute) together with the hash of the previous node and a value called a nonce to create a unique hash value that fits a set of constraints. Once a valid hash is mined, the new block is broadcast (compute) to other nodes and the transactions in that block are executed and stored (compute) written to both lightweight and full nodes (storage) across the blockchain network.

Mining is computationally expensive, so the blockchain is orders of magnitude less efficient than comparable distributed compute and storage solutions, but it’s crucial to note that efficiency is intentionally exchanged for a different property: no one entity owns the system, yet the system can still facilitate computational transactions that involve multiple untrusted parties without introducing a trusted intermediary. If you think about the number of transactions that we participate in on a daily basis where we incur some cost to engage a trusted intermediary, this is a big deal. Facebook can monetize your data in undesired ways, PayPal takes a healthy cut to move your money around, and the government can always compel Amazon to delete or hand over data that it’s storing on your behalf.

In order to incent miners to give their compute and storage to the blockchain, the creators of Bitcoin developed the concept of a digital coin or cryptocurrency that can be exchanged in to run transactions on the blockchain. Anyone that wants to write to the blockchain ledger has to offer a small number of coins for their transaction to be processed. The cryptocurrency cost of executing a transaction on the blockchain is linked to the demand for running compute on the network and inversely linked to the computing power connected to the network. The cost in terms of a fiat currency like the US Dollar is also obviously linked to the going exchange rate between the fiat currency and the cryptocurrency, thus the cost in USD to run a transaction on the Bitcoin blockchain has increased steadily of late: in late Q3 of 2017 the cost of writing 200 bytes to the Bitcoin blockchain ledger within 30 minutes was roughly $3-4 USD worth of BTC.

Because of this need to move currency from one party to another, the original application that was baked into Bitcoin’s blockchain was the exchange of the Bitcoin cryptocurrency between parties. Newer blockchains have built on the Bitcoin foundation and embraced the idea of more generic Smart Contracts that allow for arbitrary code to be executed directly on the blockchain. For example, the creators of the Ethereum blockchain have implemented a runtime environment on blockchain for Smart Contracts written in a language called Solidity that is Turing complete, which means that in principle, it can be used to solve any computational problem. The result is that blockchains like Ethereum look similar to cloud computing service in that they allow for arbitrary distributed compute and storage, yet they also display the interesting property of being able to facilitate computation that involves multiple untrusted actors without a single trusted third-party controlling the service. Efforts are underway to bolt this kind of behavior onto the Bitcoin blockchain via sidechains like Rootstock.

That was a lot to grok, but it’s really impossible to critique the current commentary on blockchain and cryptocurrency without at least a high-level understanding of how the pieces fit together. So with that all in mind, let’s dive into a few recent criticisms from high-profile individuals in the financial sector about both Bitcoin specifically and blockchain and cryptocurrencies in general.

“Bitcoin doesn’t have any intrinsic value…”

One extremely common narrative from people that come from the financial world recently is that coins like Bitcoin don’t have any intrinsic value. Just a few days ago, Nobel Prize-winning economist Joseph Stiglitz said that “Bitcoin is successful only because of its potential for circumvention, lack of oversight. It doesn’t serve any socially useful function.” JPMorgan Chase CEO Jamie Dimon has claimed “the only value of Bitcoin is what the other guy will pay for it.”

If you made it through my quick primer above, then you already understand why Stiglitz and Dimon are incorrect. Coins like Bitcoin and Ether can be exchanged for compute and storage on a massive supercomputer with some very compelling properties that allow you to do things like executing transactions between untrusted parties without a trusted intermediary. If you believe that an increasing number of applications will be written and deployed on blockchain to disintermediate our life (and if those currencies are architected in a way that limits velocity) then the value of these currencies will inherently go up as the demand for compute and storage on blockchain increases.

It’s worth pausing here for a moment to mention that there are a few very different kinds of cryptocurrencies floating around today. The first kind is typically called a utility token that has the intrinsic property of being exchangeable for some kind of service. Bitcoin and Ether are both utility tokens because they have the intrinsic property (coded directly into the token and blockchain) of being exchangeable for compute and storage. The second kind of token is often called a tokenized security because it functions more like a traditional security that just happens to be exchangeable on a blockchain. A tokenized security has no intrinsic value but may have value ascribed to it by extrinsic means. For example, a legal contract may promise a share of the future revenue streams of a corporation pro rata to the holders of a specific kind of token. I suspect that people like Stiglitz and Dimon are completely missing the power of blockchain as a cloud computer, so they’re mistaking utility tokens for a tokenized security that is linked to very little value.

“I’m excited about blockchain, but not Bitcoin…”

A second popular thread is that Bitcoin and similar technologies are interesting, but not in their current implementation. One flavor of this attack is that blockchain technology is compelling but cryptocurrencies are not. Another related flavor is that the existing decentralized blockchain implementations will be replaced by blockchain implementations that are controlled by governments and corporations. World Bank President Jim Yong Kim noted that “blockchain technology is something that everyone is excited about, but we have to remember that Bitcoin is one of the very few instances.” He went on to emphasize that the importance of blockchain is the speed with which it can facilitate transactions, drawing parallels to Alibaba’s infrastructure that can facilitate large transactions in seconds. Former Federal Reserve chair Ben Bernanke espoused a similar view when he talked about how Bitcoin would fail but blockchain was interesting and would help federal banks improve their existing payment systems.

Again, this line of thinking is flawed. As noted above, blockchain is an intentionally inefficient system because it trades efficiency for decentralization. It’s hard to see why a bank or government would want to implement an inefficient technology for no reason if decentralization isn’t a desired property. Banks already run on digital systems that can facilitate transactions between people, so what exactly is blockchain bringing to the table? Further, that decentralization can only be maintained if coins are woven directly into the fabric of the blockchain to compensate miners, so the idea of implementing a blockchain without a linked cryptocurrency doesn’t make a lot of sense.

“Bitcoin is an unreliable store of value…”

Another part of the conversation about the value of Bitcoin is centered on whether it will prove to be an effective store of value. A store of value is a mechanism that allows people to preserve facilitate the exchange of wealth and to preserve wealth across both physical space and time. To accomplish this the medium of storage must exhibit a few properties: it must be liquid, it must be scarce, it must possess longevity, and people must be willing to assign a value to it. Historically, stores of value have included things like precious metals, gemstones, livestock, real estate, and fiat currencies.

Some recent challenges to the validity of cryptocurrencies like Bitcoin as a store of value have focused on whether the currencies will continue to exhibit those required properties of a store of value. In the article that was linked above, Jamie Dimon states that “governments are going to crush Bitcoin one day. Governments like to know where the money is, who has it and what you’re doing with it.” In essence, his comments are an attack on the longevity of Bitcoin as well as its liquidity in markets as they become more regulated. Economist and author Raoul Pal claimed that Bitcoin was an unreliable store of value because the group of developers that controls the underlying codebase can change the code: “Even if they don’t change the formula, the fact that they could? That’s enough to say it’s not a long-term store of value.” Pal’s statements cast a doubt on Bitcoin’s scarcity (since software engineers could “print more money”) and whether people should trust the people at the helm enough to assign value to the currency.

The reality is that any government that bans cryptocurrency will miss out on the next great wave of innovation. Where would the US be today if the government issued a ban on all HTTPS traffic because it disrupted the way that intelligence was previously collected? The risk of rogue updates to the codebase is slightly more real, but it’s important to note that there are three groups of actors in each blockchain ecosystem that work as a set of checks and balances against each other: developers, miners, and cryptocurrency holders. The split between Ethereum and Ethereum Classic is a real-life case study in what happens when those groups move in different directions, and it will forever be a warning to the development communities for other blockchains.

Where To From Here?

None of this means that Bitcoin and other cryptocurrencies are destined to continue their meteoric rise. Blockchains have real challenges as they try to scale; when an app like CryptoKitties pushes your network to its limits, you have work to do. Cryptocurrency exchanges are still a major vulnerability of the system and market manipulation is possible at current volumes. For example, it’s widely speculated that the current price of BTC is being propped up by the fraudulent issue of Tether and that if USDT and Bitfinex implode, they will bring all cryptocurrencies along for the ride. All of these risks are real.

But as both a Software Engineer and a VC, I can tell you that I see a lot of companies making big bets on blockchain and using it as the Operating System for applications that were previously impossible to build and will change our lives. Those apps aren’t in production or operating at scale yet, so the analogies between the current environment and the dotcom bubble are reasonable: there may be a crash that is followed by a long period where apps are deployed, adoption grows, and the ecosystem justifies the valuation. Or, maybe, the current lofty valuation on cryptocurrencies is correct for a technology that has the potential to disrupt both the financial sector and cloud computing and near-term growth will continue.

When Clay Christensen introduced the concept of “disruptive innovation” in The Innovator’s Dilemma, he explained that incumbents can’t pursue disruptive innovation when it first arises because the opportunities aren’t profitable enough and the development of disruptive innovation would take scarce resources away from sustaining innovation that is required to keep up with the competition. As the disruptive innovation matures, it begins to capture share up-market, and the incumbent can’t react quickly enough.

Jamie Dimon claims that blockchain isn’t worth his attention because JPMorgan Chase moves $6T in money around the world every day while the daily trading volume of all cryptocurrencies is around $10B. Ironically, with a total market cap of roughly $370B, the basket of all of the cryptocurrencies in the world is now more valuable than JPMorgan Chase. Are major industries going to be disrupted in the next decade? Time will tell, but I’m betting on crypto.