Philosophical questions like "what is time" are different for developers. For developers, it is a critical engineering question around time zones and representation. A question with many right answers! A question that can cause unlimited pain if you have multiple right answers in your system.
What is time? What is money? If you've ever wondered how expensive these questions can be to answer, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Isaac and I argue that Rewrites aren't an alternative because they almost never succeed. But if you follow our advice on Iterative Replacement, will you be trapped in legacy frameworks? Will you be stuck facing the future with one hand tied behind your back?
If you've ever wanted to do a rewrite so that you can leapfrog technology, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
The SaaS Business Model can be confusing to anyone not intimately familiar with how it works. For developers, this makes it hard to understand priorities, see the levers, and understand their impact. This post is going to try a simple metaphor.
The SaaS Business Model is like pumping air into a balloon with a leak.
The pump represents new customers, the leaks are churn, and customers are the air in the balloon - the life breath of the SaaS.
You want to pump as hard as possible to get as many customers as possible. But the more customers you acquire, the more the balloon fills, the more pressure there will be pushing against the leaks.
SaaS Always Needs New Customers
A SaaS company can never stop acquiring new customers, because it can never stop losing customers. Through no fault of their own, the SaaS customers' needs will change and some will go out of business. Without a steady stream of new customers, the balloon will deflate and the SaaS will go out of business
The Pump And The Leaks Are Tradeoffs
The Pump is the force that brings in new customers. There are many ways to acquire new customers - marketing, sales, and referrals are some of the major ones.
The Leaks are the things that cause customers to churn. Some are outside of your control; customers go out of business. Most are things you can control like price, easy of use, and buggyness.
The pump has a huge impact on the leaks. A SaaS that brings in customers via Enterprise Sales is much more immune to issues with performance, ease of use, and bugs than a SaaS that brings in new customers through referrals.
Features And Quality Can Be Tradeoffs
A common confounding example is when a SaaS brings in new customers through a steady stream of new features. This sets up a model where Features and Feature Quality have become tradeoffs. For developers, this manifests as strange and confounding choices - create lots of features very quickly, and then occasionally go back and fix bugs.
Features bring in new customers, they optimize the pump. Quality reduces churn, it helps patch the leaks. Depending on the pressure in the balloon it may make sense to pump harder, or it may make sense to slow the leaks. Churn is a laggy indicator, problems take a while to drive customers away, and fixing the problem doesn’t immediately reduce churn. Developers also aren’t usually privy to the data so the switch from features to quality can appear with little warning.
Referrals Make Quality Additive
Alternatively, when the pump is driven by referrals, that can drive developers to prioritize Quality and make Price the tradeoff. Software can be made easier, faster, prettier, and more reliable by throwing money at the problem. Referrals come from happy and satisfied customers, great service at a great price.
Conclusion - The SaaS Model Requires Tradeoffs
The SaaS Business Model can be confusing because the drivers can be obscure. Business tradeoffs aren’t static, they change based on the source of new customers and sources of churn. This can be especially confusing for developers because churn is a lagging indicator and the switch from working on acquiring new customers to reducing churn can be sudden.
Above all else, churn is inevitable and you must always be working to acquire new customers!
As a consultant, how do you handle a potential client's risky software setup? In this episode we detangle red flags from opportunities; and work through the legal and ethical need to do more than just do what the client asks. We cover the questions and discussions consultants need to protect themselves, their business, and their customers.
If you've ever wondered if you can, or should, help a client with a risky setup, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Once upon a time a Software Engineer and a Mechanical Engineer needed to lift the leg of a table and slide a carpet underneath. The Software Engineer, being younger, offered to lift the table with his hands. This would create enough room for the Mechanical Engineer to slide the carpet under. They would repeat the process for each leg.
The Software Engineer lifted with all of his might, but could not raise the table. “The worker is not powerful enough”, he declared. “I will call in some more people. By scaling out the number of workers, we will reduce the amount of power each worker needs. When we have sufficient parallel workers, the table leg will rise.”
The Mechanical Engineer replied, “Get me a 2x4 and a brick.”
And so the edge of the table was lifted. “I estimate that the lever gives me about 20:1 leverage,” the Mechanical Engineer said, holding the table up with one hand.
Are communication gaps tech debt? Do they cause tech debt? Can they be worse than tech debt? Austen Tucker joins us this week to ponder communication's role in building software.
If you've ever wasted weeks writing great code that never got used, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Can changing jobs be a rewrite on your career? In this episode we work through the similarities and differences and see if changing jobs is a Rewrite, and if our mantra of Never Rewrite still holds.
If you've ever thought about getting a new job because you hate your current one, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Giving constructive feedback on software is difficult. You need to approach it with empathy for past developers, context on the problem, and separation between the code and the developers who wrote it.
If you've ever given feedback that was not only ignored, but made the developers mad, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Tech debt is a nebulous concept to anyone who hasn't worked as a developer. Yes, tech debt makes things harder and slower, but why? What is it like? In this episode Isaac and I offer a useful analogy: Tech Debt is like construction on an old house.
If you've ever struggled to explain why tech debt is so difficult and unpredictable, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Are bad practices around testing and releasing cultural or technical? "Bad" changes as a company grows and matures, and what was bad for a startup may not be bad for more established companies. Similarly, holding on to startup practices to long can have a devistating impact on accountability.
If you've ever wondered why your company can't kick bad habits, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
