Over the past 6 years as the co-founder and CTO of GetHuman, I’ve spent a significant portion of my time thinking about how software can be used to help improve customer service. While there have no doubt been recent innovations across the industry that have greatly improved the efficiency of customer service from the company’s point of view, the sad fact is:

Despite some technical innovations, most customer service still stinks (from the consumer’s point of view)

Why is that?

In this 4-part blog post series, I will make the argument that there are actually two fundamental problems at play here:

1. Customer service software built for companies only helps consumers insofar as companies perceive that it’s in their own self interest.
2. Customer service software built for consumers tries to do what is in the best interest of the consumer, but that effort is often compromised by the need to make money and/or their relationship with companies.

After we go over both of these issues in depth, I will present a few thoughts on how these issues can potentially be overcome in the future and what we can do to improve the state of customer service as a whole for everyone across the board.

Up Next…

In Part 2 of this 4-part series, I will explain how the economic incentives behind customer service software can adversely affect customers.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

This is Part 2 of a 4-part series about what is wrong with the customer service software industry and what we can do about it.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

In the first part of this series, I explained why The Customer Service Software Industry is Fundamentally Broken. In this post, I will go into a little more detail and explain how the economic incentives behind customer service software can adversely affect customers.

The incentives are different depending on whether the software is geared toward companies or consumers. Let’s talk about each in turn.

Customer Service Software for Companies

There are many different reasons why customers get frustrated by the customer service provided by companies. For the purpose of this article, however, it’s important to distinguish between issues the company is incentivized to improve (i.e. customer and company incentives aligned) versus frustrations purposely caused by the company (i.e. incentives NOT aligned).

Types of Customer Service Issues

1. Customer needs information — incentives aligned
2. Customer reports a bug — incentives aligned
3. Customer makes standard operational request — incentives aligned
4. Customer wants to cancel service, reduce rate or perform any action that goes against standard policy — incentives not aligned

Aligned Issues

I’m not saying there aren’t challenges today with fulfilling customer service requests in the first three categories. There are. I’m just saying that it’s in the best interest of the company to resolve those challenges and therefore customer service software vendors will likely continue to innovate here.

Non-aligned Issues

The much more problematic area in the long term is #4.

Customer service software built for companies will never make it easy for customers to do something the company doesn’t want them to do.

Any significant improvement for this category of customer service issues will have to come from the other side of the fence (i.e. software built for consumers).

Customer Service Software for Consumers

In theory, consumer software should be built to favor the consumer at all times. In reality, however, this largely depends on answers to the following questions:

What‘s the relationship between the software and the company?

A customer service issue is by definition an issue between a consumer and a company. In order for consumer software to help resolve that issue, the software product has to jump in the middle of that interaction. When that happens, the software has one of two choices:

1. Remain 100% completely independent from the company to ensure the consumer’s interest is always favored.
2. Establish integrations/relationships with the company in order to enable certain features and/or solve certain types of customer service issues.

These options are, in most cases, mutually exclusive. The tighter the relationship with the company, the more the independence and integrity of the consumer software is compromised. However, in many cases, some sort of relationship with the company is needed in order to service the customer.

In short, there is no perfect answer here and most consumer software is forced to walk a fine line between the customer’s interest and the requirements needed to integrate with the company.

How does the software product make money?

Nothing in life is truly free. Consumer software has to make money at some point in some way. That means consumer software is faced with a second difficult choice:

1. Charge the consumer
2. Charge the company
3. Charge a third party (i.e. ads)

Each of these options have advantages and disadvantages.

Charging the consumer ensures the highest likelihood the interest of the consumer is prioritized, but as I have (painfully) learned during my 6 years at GetHuman:

Most consumers will not pay for customer service

Charging the company is usually the most profitable option, but it has the obvious strings attached.

Charging a third party that is not involved in the customer service transaction (i.e. in most cases, ads) seems like the most viable option except that you often need to attract a A LOT of users in order to make significant revenue.

For example, with ads my general rule of thumb is that you need 1m+ monthly users to have any chance. Even then, the software won’t be much more than a side lifestyle business unless you can continue to increase one or two orders of magnitude (i.e. 100m+ monthly users) beyond that.

Up Next…

So, consumer software is clearly a better candidate to fix the fundamentally broken part of customer service. However, as alluded to earlier in this article, consumer software can be tricky. Part 3 of this 4-part series goes a little deeper into the different categories of consumers software.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

This is Part 3 of a 4-part series about what is wrong with the customer service software industry and what we can do about it.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

Part 1 of this blog post series provided an overview of why The Customer Service Software Industry is Fundamentally Broken. Part 2 explained how the economic incentives for customer service software makes it difficult at times to do what’s in the best interest of the consumer. The conclusion in that article was that consumer software is more capable of doing what is right for the consumer than commercial software.

So, let’s dive into the 4 different categories of customer service software available today for consumers. To be clear, nothing is perfect. If there were, then customer service would not be broken. The goal of here is to learn from what works and what doesn’t with existing software so we can start to envision a new bigger, better, more bad*ss solution in the future.

Category: Content Website

• Example — GetHuman
• Customer service need addressed — Information/troubleshooting
• Business model — Ads/Referrals
• Relationship to companies — Content curated by website and/or website community (i.e. so company usually not involved)
• Advantages — Can give information that the company doesn’t want to reveal (ex. explaining how to cancel). Also, can provide cross-company and cross-product information (ex. comparing product features).
• Challenges — Can be hard to keep information in sync with changes at each company. Incorrect and/or out of date information is often even worse than no information. FYI, GetHuman does a great job of this, but it takes a pretty massive effort behind the scenes.

Category: Dispute Management

• Example — Better Business Bureau
• Customer service need addressed — Resolving dissatisfaction with the service provided by a company
• Business model — Selling data and/or accreditation to companies
• Relationship to companies — Often companies can get more favorable ratings/access if they pay more
• Advantages — As trusted 3rd party, has leverage to demand more from companies for the customer.
• Challenges — Since revenue comes from companies, dispute managers often need to walk a fine line. This can lead to more favorability on companies than they deserve in some cases.

Category: Service Optimizer

• Examples — BillShark, Trim
• Customer service need addressed — Monitoring service usage and facilitating changes that are most favorable to consumer (ex. canceling service, switching service, lowering rate)
• Business model — Charging customer (typically either flat fee or percentage of money saved)
• Relationship to companies — Contacts company on your behalf, so usually no direct relationship to the company. There is always a fear, however, the company will make it harder for them to work on the customer’s behalf. That fear can at times indirectly push the company’s interest ahead of the consumer.
• Advantages — Usually able to do what is best for the customer. In many cases, these services also help customer plan ahead of time to prevent potential issues in the future.
• Challenges — Companies make it just as hard for these service providers as they do for the customer (if not harder). These services almost always involve manual, resource intensive work that is difficult to scale and optimize. Also, many consumers don’t like to pay for this type of service.

Category: Customer Service “Insurance”

• Examples — Service, Lola
• Customer service need addressed — Top tier concierge customer service that you get before you have any issues (i.e. just in case something happens down the road).
• Business model — Charging customer (typically either monthly service fee or percentage of money saved)
• Relationship to companies — Similar to Service Optimizers, these services often work on behalf of the customer when they contact a company.
• Advantages — Regardless of how bad customer service is at the companies you deal with, you will always be treated like a rock star.
• Challenges — All the same downsides as Service Optimizers. Also, it’s nearly impossible to provide top tier customer service for every company in every industry. That is why these service providers more often than not focus on just one industry or niche (ex. Travel).

Up Next…

Now that we have a lay of the land, the last installment of this blog post series will lay out some guidelines for what it will take to create a solution that can help un-break customer service and make life better for all of us.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

This is the final installment of a 4-part series about what is wrong with the customer service software industry and what we can do about it.

1. The Customer Service Software Industry is Fundamentally Broken
2. Customer Service Software Economics
3. Categories of Customer Service Software Built for Consumers
4. Un-breaking Customer Service

In the first three parts of this blog post series, we talked about why and how customer service software is fundamentally broken. The tl;dr is that it’s hard to navigate the fine line between the best interest of the consumer and features that require help from the company.

I’ve been one of the brave souls walking that fine line for the past 6 years as co-founder and CTO at GetHuman. I would never claim that GetHuman is the ultimate answer (yet 😉), but our years of experimentation and exploration have lead me to believe that the following 6 characteristics are essential for any software that aims to dominate the industry and un-break customer service.

1. Consumer Technology

It should go without saying that the solution is going to have to be on the consumer side. Commercial software vendors will never work against the best interest of companies.

Sure, commercial vendors could try and convince companies that certain changes are in their best interest despite their reservations, but no salesman in their right mind is going to push that type of “controversial” conversation very far.

2. Valuable Independent Behavior

The consumer software needs to have features that are extremely valuable to consumer and which do not require any direct relationship with companies. This will ensure interests are aligned with the consumer.

For example, this could include high quality information about the company and/or their products curated from knowledgeable experts in the community.

3. Leverage Over Companies

The consumer software product needs to eventually gain some form of leverage over companies which will allow for more powerful features and services without any strings attached. More specifically, there needs to be a situation where there is huge upside for the company to interact with the product and no downside for the consumer software to NOT interact with the company. In other words:

You need me. I don’t need you.

The obvious example here is if a significant portion of a company’s customers was using a particular consumer customer service product. In that situation, the consumer product would have the power to make a significant positive or negative impact to the underlying company.

4. High Growth Business Model

Now, before you say “well, duh”, you should realize that most consumer software for customer service gets this wrong. Typically, one of two critical mistakes is made with their business model:

1. Just focus on user growth and don’t worry about making money until later. This works with some consumer software, but I’ve never seen it work in the customer service space. At the end of the day, someone has to pay for the party.
2. Focus on low hanging fruit revenue with no clear path to high growth. This is VERY common and again doesn’t usually work with consumer customer service software. The typical result of this strategy is enough revenue for a lifestyle business, but nothing that could rapidly grow to capture the entire market and change the world (which is what we are aiming to achieve).

The problem with both of these is that there is an assumption a high growth model can be “figured out later”. In reality, most high growth models require fundamental changes in the product that are really difficult to simply add on down the road.

An example of a more viable high growth business model for this situation is to have the customer service software also provide purchase suggestions (making money off referrals). This can be tricky to implement, but I believe if you’re able to earn the consumer’s trust dealing with customer service issues, you can parlay that trust into suggestions for net new purchases. Referrals make higher margins than ads right off the bat and your value per user should grow exponentially as you get more users and become more of a trusted source.

5. Organic Search + {{ somethingElse }}

Customer service is by nature a reactive experience. A problem happens (often seemingly out of nowhere) and people react to it by contacting customer service. They don’t plan for it and they often would rather not think about it if they didn’t have to.

The reactive nature of customer service makes product marketing VERY difficult.

Organic search is extremely useful as a customer acquisition channel since it fits in perfectly with a common process people use to resolve customer service issues (i.e. doing a Google search for their issue and/or contact information for the company). The only challenge with organic search as the only channel is that it is often unpredictable even for the most experienced SEO experts.

Organic search is table stakes, but it’s not enough.

In order to grow really big, really fast (i.e. exponential growth) and take over the industry, consumer software also needs a way to reliably acquire users on a more proactive basis. This could mean a second marketing channel such as using influencers or it could mean focusing on an acquisition loop like referral programs.

Regardless of what it is, the point is that you need to have more control over growth than provided by organic search. You need to know that if you pour money into marketing it will yield a positive result on a consistent basis.

6. Sticky

Customer service is by nature unpredictable, ephemeral and sporadic. Even if you build something that is able to find a consumer at the exact moment of a problem and you are able to successfully resolve that problem quickly, what are the chances that consumer will remember you the next time they have an issue?

Not bloody likely.

Well, at least not without some other reason for users to come back to your product on a regular basis. That’s why it’s critical to combine the core customer service resolution feature with at least one other high value retention loop feature (ex. a popular daily newsletter). Otherwise you would have to attract net new users every month and that is typically an unsustainable strategy.

End Game

Customer service is fundamentally broken because companies have a much greater influence on most of the software mediums used to facilitate communication and resolution. In order to un-break customer service, we need a new medium that is fully capable of resolving customer service issues while remaining largely independent from company influence.

Easier said than done.

There’s a graveyard of consumer startups out there that have tried and failed. Many of the ones I know failed because they were missing one or more of the 6 characteristics mentioned in this article. In my opinion (and from my experience), these characteristics are not just “nice to haves” but requirements for effectively resolving customer service issues in the best interest of the consumer at scale.

And THAT is the end game. Flip the script so the interest of the consumer is more valued and create an environment where companies are incentivized to do better. In other words, the consumer wins, the software vendor wins, and (in the long run) the companies with the best customer service win.

😊

Call to Action

We’re working hard at GetHuman to try and fulfill the vision outlined in this article. We want to un-break customer service.

The only thing is, we can’t do it alone.

I am a firm believer that competition is good. There are many different paths to success and the learnings from someone on one path can help others on the way to the same goal. Some of the content in this article comes from what I have learned watching hundreds of other consumer products in our space. My hope is that though this 4-part blog post series and future articles I will be able to help inspire and guide more entrepreneurs toward this same vision.

More than anything, I want this problem solved. I want better customer service. Join me and let’s venture down this path together.

👊

The content of this article comes from work I have been doing on three different projects: GetHuman, Swish, and a new secret app for my upcoming ng-conf 2018 talk called Super-Powered, Server-Rendered Progressive Native Apps.

In an ideal world, you could build one application that works consistently and perfectly on all platforms (i.e. web, iOS, Android, etc.) without worrying about the unique details of any one individual platform. Just code it up in some generic way and it just magically works everywhere. Unfortunately, we don’t live in that world today and any attempt to build a large multi-platform app under any other impression will inevitably lead to a world of pain, anguish and frustration (and/or a low quality app).

The problem at its core is that each platform has its own unique strengths that are often diminished or even completely eliminated by heavy abstractions. That doesn’t mean multi-platform development is bad. It’s just that (in most cases) it makes more sense to follow a slightly different approach. One that focuses more on building multi-platform products instead of multi-platform apps.

Before we go over this solution, however, let’s first talk in a little more detail about the problem.

The Problem: Heavy Abstractions

As mentioned, the main problem with multi-platform development is when a higher level abstraction (i.e. a facade) is too heavy and ends up adversely affecting some of the strengths of the underlying platforms. The term “too heavy” in this context, however, is completely subjective and depends entirely on the requirements of whichever app is using a particular facade.

So, that begs the question: how do we determine whether or not a multi-platform facade is too heavy for an app?

When Facades are Good

Facades that abstract multiple platforms can be really useful and valuable AS LONG AS the following conditions are met:

• Key features available — All of the key features of underlying platforms that are needed by an app need to be easily available (i.e. without jumping through a lot of hoops).
• Performance sufficient — The performance characteristics that matter for an app must be close enough between the facade and the underlying platforms.
• Easy to implement and maintain — The facade needs to save you time and money by making development easier. Otherwise, why bother?

When Facades are Bad

In general, facades are more likely to be a poor fit for more apps when:

• The facade tries to do too much — The more features in the facade and the more the it tries to do, the harder it is to get right. Conversely, the thinner the facade, the greater the chances of success.
• The facade is too high level — A generic wrapper around low level utilities for different platforms is usually pretty easy to build and maintain. A generic frontend view that is meant to abstract different platform specific views is really hard to pull off well.
• The facade is custom — This may seem counter intuitive at first. You may think that if a company builds a thing, they will ensure it meets all their own requirements. Perhaps this is true sometimes, but in my experience a more likely outcome is that custom multi-platform facades degrade quickly over time into a complex mess of delicate hacks that no one wants to touch for fear of breaking the entire system.

Why “write once, run everywhere” is an anti-pattern

The idea of “write once, run everywhere” is an anti-pattern when you treat it as the goal instead of a means to an end. When your primary objective is to maximize code re-use, you are more likely to choose facades that are missing key features and/or have significant performance issues and/or are difficult to maintain.

Your true goal should really be building the best possible version of your product. That may or may not involve multiple platforms and that may or may not involve different levels of code sharing.

The Solution: Multi-platform Product with Single Platform Apps

This article uses a lot of terminology that likely has different meanings to different people. The solution I am proposing for multi-platform development requires that we are all have the same definition of a platform, a product and an app as well as how they should all fit together.

What’s a Platform?

A “platform” for the purposes of this discussion is a software environment that provides a set of constraints and low level capabilities for visual rendering.

One important thing to keep in mind is that there are different levels of platforms. Higher level platforms act as facades for lower level platforms. Here are some examples of different platform levels:

• Level 1— iOS, Android, web browser
• Level 2 — NativeScript, React Native (abstractions on top of iOS and Android)
• Level 3 — Ionic (an abstraction on top of Cordova which is itself an abstraction on top of iOS and Android)

What’s a Product?

A “product” for the purposes of this discussion is one or more frontend apps created with the same language, managed together and designed to satisfy the specific needs of a particular market segment or mission.

The key point here is that a product is not just one app. In many cases, a product involves a number of different apps working together for a common goal. For example, one product could include both a NativeScript app and a separate Progressive Web App as well as an administrator console on the web and a static marketing website.

What’s an App?

An “app” for the purposes of this discussion is the smallest possible deployable package of frontend views that solve a specific problem for a set of users on one platform.

There is quite a bit to unpack here, but I would imagine that this definition doesn’t necessarily match up with your own. Most people jam way too many features and give way too much responsibility to individual apps. In general, it seems much easier to simply add another feature to an existing app rather than build a new one. That is why there is a tendency to build a large, custom multi-platform facade that eventually becomes an albatross around the neck of an organization.

So…let’s not do that.

Instead of creating one massive app, let’s create one product that consists of many small apps where each deployable app unit does one thing really well for one platform.

How should all these pieces fit together?

There are many different ways to configure a product with small, single platform apps. Here is an example of one way to to do it for a JavaScript-based product called foo:

This folder structure here depicts the code in a product monorepo that has a “platform sandwich” architecture:

1. apps — A thin, platform-specific set of apps at the very top. In this example, there is a “viewer” app for NativeScript (called nativescript-viewer) and a separate “viewer” app for the web (called web-viewer). The functionality for each viewer app is similar, but the code is unique to the target platform.
2. libs — All the platform-agnostic, shared code in the middle. This layer has business logic and utilities that can be shared among all apps.
3. xplat — A thin, platform-specific set of low level libraries at the bottom. This layer contains shared code that can be used by all apps for a given platform as well as platform-specific adapters that can override generic stubs in libs (ex. uploadFile() in xplat/NativeScript can override the no-op uploadFile() stub in libs).

Again, this is just an example of how to set up your product code. It is not the only way.

Benefits of this Approach

At a high level, the goal with this approach is to get the best of both worlds: easy access to the full capabilities of any given platform while still maximizing code reuse. Specific benefits include:

• Platform-App Fit — You can choose the appropriate platform level for your app. Sometimes it makes sense to go with Ionic. Other times it makes more sense to have separate iOS and Android apps.
• Apps are Lightweight and Disposable — It’s soooooooo nice to be able to quickly build a new frontend quickly for an existing product. The world of frontend tech moves quickly and keeping your apps thin gives you a lot of flexibility to refactor/replace as needed.
• Easier to Scale Team — As your team grows larger, it gets harder and harder to avoid team members stepping on each other toes. Using this approach, team members can work on separate apps and are much less likely to inadvertently block each other.
• Easier to Understand — I have been using a version of this approach with my team at Swish for the past few months and it has been amazing how quickly new developers can get productive and how few bugs slip into production. A huge win.

Closing Thoughts

The Future

I started this article with the premise that almost any non-trivial, multi-platform app cannot be built in a completely generic way (i.e. the app will inevitably have logic for the underlying platforms somewhere).

But…things can change.

10 years ago, web developers often had to write code that specifically targeted Internet Explorer. Perhaps in 10 years from now, the web will make another huge leap to become a true first class citizen on all devices.

Who knows if that will happen, but if it does, then building for just one platform (i.e. the web) may actually become viable one day.

More on This Topic

As I mentioned earlier, we use the techniques described in this article for our spending tracker app at Swish, but I also have some other related upcoming events:

• Nathan Walker and I are building a new secret app with this approach that we are going to reveal during our talk at ng-conf 2018 called Super-Powered, Server-Rendered Progressive Native Apps.
• I am working on a blog post that will dive into the technical details of implementing all this with Angular. Follow me on twitter to hear about when that goes out.
• I am also working on a blog post to specifically talk about SSR apps and how the approach outlined in this article plays really nicely with an AMP-to-PWA UX.

If you have thoughts on this topic, please post a comment here or reach out. I am doing a lot of work in this space and could use any and all feedback. Thanks!

“Write once, run everywhere” is an anti-pattern was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

This video was me just 2 years ago at ng-conf talking about how Isomorphic JavaScript was going to take the world by fire. At that time, the idea of duplicating code in two places (i.e. once on the server for search engines and another on the client for rich user interfaces) made me sick. DRY rules!

Well…a lot has happened since then. Specifically, a few specific things have drastically affected the way I view the concept of Isomorphic JavaScript:

• I had to grow and maintain a large codebase over time. In many cases the “tricks” I used to make my code “Isomorphic” ended up causing more problems than they solved.
• My team grew much larger and I began to realize that training someone to understand the subtleties of Isomorphic JavaScript development was nontrivial (and extremely prone to error).
• The pace of shipping product features within my team grew exponentially. I eventually realized that ultra-DRY code often created tight dependencies that actually prevent fast iteration cycles (i.e. you can’t change one piece of code quickly for fear of adversely affecting many other dependent pieces of code)
• Much better server rendering solutions came around (including one that I helped build as part of the Angular Universal team)
• Trying to optimize for BOTH initial load performance and content reading versus long lived usage and rich interfaces is…well, frankly, impossible. Sure, you can sort of do an OK job at both, but they are very much at odds for when you want to have the absolute best possible experience.

I talk a little about all of this in one of my latest talks on code management at AngularConnect:

For all of these reasons, I truly believe that Isomorphic JavaScript is dead. Well…at the very least the concept of Isomorphic JavaScript where you could just take an app build for the client and then just let it magically work on the server. I don’t buy into that at all anymore.

The New “Isomorphic”

Instead, I believe the future is all about authoring your platform-specific code in one place (i.e. you can have your SEO code together with your rich client code in the same repo), but then having different parts of your app specialized for only one or the other. In other words:

• Landing Pages — Only server rendered with little to no client side JavaScript. Focused on maximum initial load performance and content delivery.
• App Pages — Only client rendered with perhaps just an app shell on the server side. Focused on the best possible rich user experience.

These two can live on the same domain with the same website (and in many cases should). For example, check out the United Airlines Phone Number page on GetHuman.com. It is only server rendered with no client side JavaScript. However, if you click on a link (for example, the “Skip Waiting on Hold Button”) you will start to interact with a series of pages that are client loaded and have some rich features.

Final Word on AMP

Oh, and one more thing…when you start to go down this path there is an added bonus. The server-only landing pages you create should be very close to the AMP specification. It shouldn’t take you too much work to “AMPify” you pages which should yield even more benefits for the user experience during initial load. I am going to be talking a lot more about this at ng-conf 2018 with my talk, Super-Powered, Server-Rendered Progressive Native Apps.

Isomorphic JavaScript is Dead… Long Live Isomorphic JavaScript! was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article describes a relatively new budgeting technique called Budget Burn Down which has already helped hundreds of thousands of people save money and achieve their financial goals.

Story Time

It was a dark and stormy night. Beads of sweat began to roll down Roger’s forehead as his eyes darted nervously back and forth between the pitch black forrest road ahead and the red warning light on his dingy, old gas gauge.

Roger was lost. Completely, utterly, hopelessly lost.

“Shit.”

Roger’s anxiety turned into full blown panic as he felt the car go dead. He frantically started pressing the gas pedal harder and harder. No go. He looked at his phone again. Still no bars.

“Shit!”

Roger managed to guide his car over to the side of the road as it slowly rolled to a stop. For a full minute, Roger couldn’t move. He sat frozen with fear staring straight ahead while his mind raced through his worst nightmares.

“How could I have been so stupid?”

Turning our Fear into Power

Make no mistake. Running out of gas sucks. Perhaps the worst part about it is that in most cases it is a fairly avoidable mistake. So, let me ask you:

When’s the last time you ran out of gas?

Don’t worry, I’m not asking you a deep philosophical question about your life or anything like that. I am literally asking, “When is the last time you were driving a motor vehicle and it stopped moving because you ran out of gas?”.

Chances are, you can count the number of times this has happened throughout your entire life on one hand. Sure, when it happens it really sucks, but objectively speaking it almost never happens. Why is that?

In most cases, it is because of the following three factors:

1. Gas costs money and is not always easily available
2. It would really, really suck to completely run out of gas (especially alone in a dark forest in the middle of the night)
3. We know how much gas we have left at any moment by quickly glancing at the gas gauge

Or, from a more general sense:

1. There is a valuable, diminishing resource
2. There are significant consequences if that resource is ever fully depleted
3. A simple, intuitive monitoring system exists to see how much of that resource is left at any given time

Whenever you can set up a situation in your life where these three conditions exist, you have the opportunity to create a powerful force for driving positive change.

The Cash Envelope System

One example of how some of this can be applied to saving money is The Cash Envelope System which has been touted for years by finance gurus like Dave Ramsey and blogs like A Bowl Full of Lemons. As explained in wikipedia:

The key idea is to store the cash to meet separate categories of household expenses in physically separate envelopes.

At the beginning of each time period (usually a week) you put cash in the appropriate envelopes. Once an envelope is empty, you can’t buy any more items from that category until the next period.

This system works really well for a lot of people because (just like with the gas gauge example) there is a clear and straightforward way to see how much money you have left to spend for a particular category (i.e. how much cash is left in the envelope). However, this system has several flaws:

• Time & Effort — Setting up and maintaining this system is non-trivial. For some people this is a feature, not a flaw. The extra effort gets them more emotionally involved in the process. For many others, however, this is too much work and prevents them from sticking with this system.
• Categorization Craziness — At first it may seem like separate envelopes for separate categories makes sense. But…what about when you have an expense for a category that doesn’t exist? What if an expense covers multiple categories? What happens if half way through a period you realize that one category should be split into two? It can get complicated.
• Unnecessarily Restrictive — The ultimate goal is to save money. Does it matter that you go over hundreds of dollars in one category if you are actually way under budget overall? If anything the categories are a means to an end.
• Non-intuitive Monitoring — One envelope is easy to monitor. A dozen envelopes? Not so much. It can take several minutes to determine your financial health at any given moment and that is way too long.
• Cash is Not Always King — Yes, there are a number of psychological benefits to using cash instead of credit cards. However, for many people (including me) those benefits are not worth the pain of dealing with cash. I would much rather get rid of my wallet altogether and use my phone to pay for everything if possible.

What some of us really need is a much simpler form of the Cash Envelope System that addresses some of these issues. That is where Budget Burn Down comes in.

The Budget Burn Down System

The best way to explain Budget Burn Down is to go back to those three conditions for driving positive change (i.e. Diminishing Resource, Significant Consequence and Intuitive Monitoring).

1) Diminishing Resource: Free Spend

What is the one primary resource we care about when it comes to saving money? Your bank balance by itself will not help here because that number only helps describe the current state. It does not capture anything related to the future which is needed for planning purposes. What we really need is something more like this:

• Expected income (or budget if no income) for a given month
• Minus expected bills during that month
• Minus desired savings goal for that month
• Minus expenses to date through the month

The resulting number from this equation is called Free Spend and it is the single most important financial metric to help you save money. This one number is more simple and can be more powerful than the many different category cash amounts used with the Cash Envelope System.

2) Significant Consequence: Spending Bankruptcy

What consequence do you think is more impactful to your daily behavior?

• Once you run out of your clothes budget you can’t buy any more clothes
• Once you run out of money you can’t buy anything

It is true that the first option can be more effective at curbing a specific bad spending habit. For example, if you were generally a frugal spender but the amazingly delicious ham and cheese croissants at Flour Bakery puts you over budget every month, then something like Cash Envelope could be really effective.

In most cases, however, saving more money requires behavioral changes across the board. Thinking in terms of individual categories can create unnecessary distractions and almost certainly waters down the potential consequences of not hitting your goal.

3) Intuitive Monitoring: Realtime Free Spend

The more simple and focused the monitoring, the easier it will be for you to understand where you stand at any given point in time and enable you to adjust your behavior accordingly. For example:

$173.53 left for 2 days this week

All you have to worry about each and every day is making sure this number is not going to drop down to zero. Forget about trying to budget for dozens of different categories or do any mental arithmetic. Just keep an eye on this one number.

The Psychology Behind Budget Burn Down

Back in 2003, authorities in city of Garden Grove, California were grappling with a big problem. Too many people were speeding through school zones. They tried a number of different tactics to curb this behavior but speeding cars continued to hit bicyclists and pedestrians in the school zones with depressing regularity.

Then, they tried something that was quite unique at that time:

“…they put up what are known as dynamic speed displays, or driver feedback signs: a speed limit posting coupled with a radar sensor attached to a huge digital readout announcing YOUR SPEED”

This experiment proved wildly successful with the average speed dipping below the posted speed limit at all Garden Grove schools. Motor vehicle accidents involving bicyclists and pedestrians dropped dramatically. The use of these dynamic displays quickly expanded throughout the state and then, ultimately, the entire nation.

The reason for this success (and the reason for the success of the Budget Burn Down system) can be explained by the idea of Feedback Loops:

“The signs leverage what’s called a feedback loop, a profoundly effective tool for changing behavior. The basic premise is simple. Provide people with information about their actions in real time (or something close to it), then give them an opportunity to change those actions, pushing them toward better behaviors. Action, information, reaction.”

I love how succinctly this captures the essence of the Budget Burn Down system.

Action. Information. Reaction.

Final Thoughts

Budget Burn Down is most definitely NOT for everyone. Some people simply prefer Cash Envelope or some other budgeting technique (or nothing at all).

However, as proved by the former Level app, it can be amazingly effective for people that want something simple and who are highly motivated by a good financial feedback loop.

Ready to get started? We just launched a new app that automates Budget Burn Down by showing your Free Spend in realtime. It’s called Swish and it’s available today on the web, iOS or Android.

Also, if you like hearing more from Jeff, keep an eye out for his upomcing ng-conf 2018 talk entitled, Super-Powered, Server-Rendered Progressive Native Apps.

Budget Burn Down was originally published in SwishMoney on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the first of a 4-part series on the best practices for organizing code repositories.

• Part 1: The Problem with Shared Code (this article)
• Part 2: How the Best Tech Companies Organize Code (coming soon)
• Part 3: Monorepo vs Multirepo Survey Results (coming soon, but fill out the survey here)
• Part 4: Repo Decision Framework (coming soon)

In this first article we define the problem and understand the challenges involved with sharing code.

Earlier this year, my company GetHuman raised money and grew from 2 engineers to 8. The good thing about this is that we were able to start writing a lot more code. The bad thing about this is that we started writing a lot more code.

The Problem

Back when it was just my co-founder and me, there were very few formal development processes. We just hacked away and pushed into production at will. It worked because we both knew every line of code. It was easy to coordinate changes because we were essentially single threaded on most projects.

That all changed after we hired 6 more developers and the new team started cranking. Not only were there more commits on a daily basis, but the types of commits became more diverse and complex. The interesting thing is that while our overall output increased, the productivity of each individual developer actually decreased. The primary reason for this can be boiled down to one simple statement:

Sharing code efficiently at scale is hard.

To be clear, sharing code is not hard. There are many different ways to share code in general and most of them are relatively easy to implement. The hard part is doing it efficiently at scale which means:

1. Multiple code modules (that share some code)
2. Multiple team members
3. High rate of change
4. Little to no loss of individual productivity

When your goal is to have all four of these conditions exist at the same time, you will almost certainly run into some challenges.

Scalability Challenges

Over the past year, most of the issues we had scaling our codebase fall into one of the following categories:

• Refactoring
• Versioning
• Testing
• Reviewing
• Consistency
• Deploying
• Size

Each category is described in more length below.

Refactoring

Let’s say that we want to change a field in a shared data model from “isSubscriber” to “subscriberFlag”. You could just publish that one line code change and let any code using that data model break or you can try to update all references to “isSubscriber” at the same time throughout your code base. Many code editors are good at doing this, but all the code must be loaded in the editor at the same time.

This can be a major source of pain as your codebase grows larger. For example, at one point, we had 42 npm modules split among 15 different repos. It was nearly impossible to use Webstorm with all of this code (it would lock up on a regular basis to re-index). VS Code is better because it generally doesn’t lock up, but intellisense is often unavailable (I suspect because of a similar need to constantly re-index code in the background).

Versioning

Whenever a downstream dependency is updated, you have a choice:

1. Let the upstream modules upgrade at some point in the future
2. Force all upstream modules to upgrade immediately

In either case, there is some overhead. With option 1, you must maintain multiple versions of the downstream dependency. With option 2, you need to update and test all upstream modules right away.

Perhaps an even bigger issue with versioning, however, is when you need to go back in time. This can be a huge (i.e. nearly impossible) challenge if your codebase is split among dozens of different repos and you need to figure out where and when a bug was introduced into the system.

Testing (for JavaScript)

In general, integration and end-to-end (e2e) tests can be tricky. For JavaScript, the challenge with testing multiple local dependencies can be best summarized by this well known JavaScript adage:

“npm linking sucks, yo”

Theoretically you should be able to npm link all your local dependencies while you make changes. In practice, however, this rarely works well when you have a large number of interdependent npm modules. The overhead involved is non-trivial (ex. see how long it takes you to npm link 3+ modules together) and a wide variety of tricky issues crop up on a seemingly regular basis (i.e. like this nasty TypeScript issue or this annoying Angular issue or this Babel issue or this Webpack issue or this other Webpack issue…you get the point).

Reviewing

We always try to keep each Pull Request (PR) as small and specific as possible. However, sometimes even small, targeted updates require changes across several different repos. Each repo involved requires the overhead of another PR. On top of that, it is hard for reviewers to understand the full scope of the change since they have to look across all the PRs involved.

There is also a question of ownership. Who is responsible for reviewing a particular PR? At scale it is not feasible to have everyone review every PR. There are actually two levels of issues here.

1. First, how do you set up a system where the right people can review the right PRs at the right time?
2. Second, how do you ensure that whatever system you setup to answer the first question doesn’t create an untenable matrix of gatekeepers who grind productivity to a halt?

Individual repo owners acting as gatekeepers can be a real problem in some organizations. When I worked at Wells Fargo, the overhead involved with convincing another team to allow us to make a particular change in “their” repo often made us think twice about making the change in the first place.

Consistency

Somewhat related to the review process is how to best keep a consistent set of standards across the entire code base. This is pretty easy with 2 or 3 developers when everyone can review every change, but what about when there are dozens of developers (or more) and they push in hundreds of changes (or more) every day?

Deploying

While we started off with many different smaller repos, we experienced some of the issues described above and at one point we tried to consolidate everything into one larger repo. We quickly ran into a major issue, however. It turns out that a large majority of the most popular deployment tools are completely incapable of effectively handling multiple disparate deployment configurations. They all expect exactly one configuration file. For example:

CircleCI

TravisCI

Codeship

You can, of course, deploy multiple packages, but they must all be part of the same configuration. This is a problem if you want to independently manage different deployable projects in one repo.

Size

Another major challenge with trying to use one repo for everything is size. The common wisdom with hardware is that it is generally easier in the short term to scale vertically (i.e. add more memory or more CPU), but it is better in the long term to scale horizontally (i.e. add more machines). This same logic holds true for code repositories as well.

The size of any given repo does not generally matter until you get to the point where day-to-day operations are affected. Some of the signs that your repo may be getting to big include:

• Cloning taking minutes to complete and sometimes fails
• Merging taking too long
• Repo not able to fit on some developer laptops

In general, dealing with a large repo can be troublesome at best and will only get worse over time unless steps are taken to deal with the size (more on that in Part 2 of this series).

OK, so what do we do about all this?

I am fairly certain that almost all professional software developers have encountered at least some of the issues described in this article at some point in their careers. Many of these developers do truly care about finding good solutions so that they can share code efficiently at scale.

The weird thing, however, is that as important and prevalent as this issue is, there are not a lot of great resources out there. There are no doubt many articles written about specific solutions at specific companies, but I have found almost all of them lacking in the detail and flexibility needed to implement the solution I need for my current situation.

So, I have two very specific goals for this 4 part blog post series:

1. Create a decision framework that anyone and everyone can use to help them figure out which solution(s) would work best for their current situation.
2. Identify specific tooling and implementation details for each potential solution.

I don’t think that there is one perfect solution that will work for everyone, but I do think that many different companies have figured out solutions that work well for them. The key is to coalesce this knowledge into one cohesive and digestible package. That is exactly what I hope to accomplish with the next part in this blog post series, “How the Best Tech Companies Organize Code”.

I haven’t published the other 3 articles yet, but once I do, I will update this article with links:

• Part 1: The Problem with Shared Code (this article)
• Part 2: How the Best Tech Companies Organize Code (coming soon)
• Part 3: Monorepo vs Multirepo Survey Results (coming soon, but fill out the survey here)
• Part 4: Repo Decision Framework (coming soon)

In the meantime, please add comments below and/or hit me up on Twitter with your thoughts and opinions on this topic.

Note that this article is pretty old by this point, but is still relevant. It’s April, 2018 and I am about to speak at ng-conf 2018 about Super-Powered, Server-Rendered Progressive Native Apps so definitely check that out once it goes live.

Angular Nation is the idea that all of us in the Angular community are connected together by a common set of goals and ideals including:

1. Be a bridge builder — Respect everyone inside and outside the Angular community. Help others learn from your experiences.
2. Think at scale — Value things that allow you to scale both in terms of developers and end users.
3. All-in-one — One unified set of tools for app development that can be used on nearly every platform (i.e. browser, web server, mobile, desktop, etc.)

This website is dedicated to all the kindred spirits across the globe who believe in these ideals and want to see the Angular community grow and prosper.

Here is how it works:

1. Tell us about your experience using Angular at work
2. We may email you back to ask you questions about your experience
3. Periodically (about once a month) we will create a high-quality blog post that highlights important points and/or themes from the all the stories submitted by the community.

The goal is to have content that is entertaining, educational, inspiring and will help bring all of us in Angular Nation closer together.

FAQs

How is this different than any other Angular blog?

There are plenty of ways to get technical content about Angular. The difference here is that blog posts will focus more on people and organizations. For example, a typical technical article may explain how to best utilize TypeScript with Angular or the step-by-step details of how to use the CLI. An Angular Nation article, on the other hand, will focus (for example) on a story about how an organization initially struggled to get buy in from developers into TypeScript or the process another organization went through to decided between Angular Native, Angular Ionic and other mobile options.

Why should I submit my story to AngularNation.org?

The biggest and most important reason is that your submission will be used to help the Angular community. Other people can learn from your experience and we can start to identify Angular DX issues that need to be addressed.

A secondary benefit of your submission is that we will (at your request) promote a company and/or product that is related to your story. This is not a commercial, though. It will be a mention and a link back to whatever you want.

What if my story contains private information?

We will respect any request for privacy. Also, if your story is mentioned in a blog post you will be able to review the post before it goes live.

What do I get out of writing for AngularNation.org?

Similar to why someone would submit a story, writers should get satisfaction from knowing they are helping others in the community and there is recognition in terms of promotion for a company/product and a link.

Oh, and also you get to work with me (Jeff) and other editors who will help you generate an amazing post that draws a large audience.

Let us know if you would like to write for Angular Nation.

What else can I do for my fellow citizens of Angular Nation?

So glad you asked. There is so much you can do to help others, but here are a couple ideas:

• Participate in conversations on the Angular gitter channel
• Help fix GitHub issues
• Sign up as a volunteer

Note that if you sign up as a volunteer, the short term process will involve a simple email back with some ideas. Eventually, though, we will refine this process and start automatically matching you up with specific areas of need.

The author, Jeff Whelpley is the CTO of GetHuman. GetHuman is the place you go for things like finding the United Airlines phone number. Also check out his latest project, a simple spending tracker.

Angular Nation was originally published in Angular Nation on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am just starting to dive deep into NativeScript with Angular and I realized the one thing that really bothers me about it. No, it is not the single thread limitation (that will be resolved very shortly). It’s the name. I know this may sound silly, but despite recent growth, I just think it would greatly benefit the adoption of both NativeScript and Angular if the integration between the two was renamed “Angular Native”.

Here are my reasons for suggesting this change:

1. Short and sweet — “NativeScript with Angular 2” is a mouthful and not necessarily intuitive. I know this is non-scientific, but “Angular Native” just sounds and feels better to me. After some quick polling of the community, many others seem to feel the same way.
2. Juxtaposes React Native — Let’s be honest here. NativeScript is not competing that much for mindshare with Ionic or other Cordova-based technology. Ionic has a completely different approach, feature set and goals (perhaps the subject of a separate blog post). NativeScript is, however, going directly head-to-head with React Native. As such, why not just simplify things for developers. React Native is to React as Angular Native is to Angular. See? Simple.
3. Helps NativeScript adoption — Did you notice how much bigger the TypeScript community got when it became the de facto language of choice for Angular moving forward? The name “Angular Native” implies a similar de facto choice and would likely lead to the same uptick in NativeScript adoption.
4. Helps Angular adoption — There a number of local organizations I know of in Boston that initially chose to adopt React because of React Native. They wanted to build a native mobile app with JavaScript and React Native seemed like the only viable choice. Once they started using React Native, then it made sense to start using React in other places as well. I have no problem whatsoever with anyone using React. I really like React. The thing I don’t like is when developers or organizations make decisions based on hype. The reality is that NativeScript is just as good as React Native. The difference between them (just like the different between Angular and React) is more a matter of philosophy and approach than capabilities. By using the term “Angular Native” what we are implying is that you can do the same type of thing with Angular as you can with React. This focuses the decision of React vs Angular more on what fits in best with their team rather than whether or not one capability exists. When that happens, it is my belief that Angular adoption increases (another topic for its own blog post in the future).

In one sense, it’s just a silly name. Who cares? It is my experience, however, that names really do matter when it comes to perception and the ease at which ideas can be spread. The impetus for this article really came from my desire to have an easier way to convey what I am talking about to other developers. I have already started reaching out to people on the NativeScript and Angular sides to see if we can gain consensus about this so we can do an official re-brand. However, even if that doesn’t work for whatever reason, I am going to just start unofficially calling it “Angular Native” and I encourage you to do the same.