Sherman On Software

Sherman On Software Latest

  • The Never Rewrite Podcast, Episode Seventy-Six, Aligning Your Company Standards to its Lifecycle Phase

    The Never Rewrite Podcast, Episode Seventy-Six, Aligning Your Company Standards to its Lifecycle Phase

    Guest Dustin Rea joins us to discuss the importance of aligning a company’s standards and processes with its lifecycle stages. The discussion covers five key phases: the MVP phase, where the foundation is built; the Product User Fit phase, focusing on understanding customer needs; the Product Market Fit phase, solidifying the offering; the Scaling Up phase, managing growth; and finally, the Multi-Product Platform phase, where companies expand their offerings. Each phase presents unique challenges and requires different approaches to maintain quality and efficiency.

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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!

  • Collaborative Breakdown: Estimating Full Projects

    Collaborative Breakdown: Estimating Full Projects

    Have you ever been asked to fully estimate a full project so that someone else can decide if it is worth pursuing?  Did the request set off alarm bells in your head?  

    It should!  Estimating full projects is a sign that the collaborative process has already broken down!  

    Estimating full projects is a trap that prevents developers from bringing their most important skills to bear.  Instead of collaboration towards a common goal, estimation pushes toxic all-or-nothing demands:

    • The project has a value, but it isn’t being shared with you.  Instead the project owner is asking for an estimate; and it needs to be less than the project’s value.  If your estimate is above the line, you’ll get pressure to revise the estimate down.  Worse, your estimates will often be ignored and timelines will be dictated.  All so that the project will hit numbers you’ve never seen.
    • You are a professional software developer and you have to accept their diagnosis about the software solution.  Is this project the best way to pursue the opportunity?  Could you do it faster and cheaper some other way?  Doesn’t matter; estimate this project.  Your expertise and creative inputs have been rejected.
    • The project will be a big bang deliverable.  You’re given a scope of work and asked how long it will take.  The asker wants the full project.  You’ll have to fight to iterate, make small releases, de-risk, or even prove the concept.
    • The project scope will always miss some requirements; the larger the project, the larger the miss.  The misses will blow out the timeline, and you will get blamed for missing the estimate.

    The alternative is a collaborative process!

    Instead of pressure for your estimate to come in below an unknown ceiling, you can scope last.

    Instead of pressure for you to accept a project, you can work together to shape the project.

    Instead of pressure for you to deliver a giant project in one perfect step, you can work together to deliver iteratively.  

    You even save all of the time spent creating a project plan, estimating the plan, and deciding whether the plan is worthwhile!

    Pushing back will uncomfortable the first few times.  The first time you have a conversation that starts with “I see this opportunity, let’s talk about how we can seize it”, it will all have been worth it.

  • The Never Rewrite Podcast, Episode Seventy-Five, Rewriting is Gambling – A Lesson in Risk

    The Never Rewrite Podcast, Episode Seventy-Five, Rewriting is Gambling – A Lesson in Risk

    Isaac and I discuss the inherent risks associated with software rewrites, emphasizing how rewrites push risk to the end of the development cycle. The discussion highlights the need for iterative development and the significance of delivering independent components to ensure project success, particularly within the SaaS model, which thrives on continuous improvement and customer satisfaction.

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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 Never Rewrite Podcast, Episode Seventy-Four, Musketeering

    The Never Rewrite Podcast, Episode Seventy-Four, Musketeering

    Isaac and I explore the concept of ‘musketeering’ in software development, emphasizing the importance of collaboration in solving complex problems. We discuss the challenges of legacy code, the necessity of testing, and the strategy of ‘divide and conquer’ to tackle intertwined issues effectively.

    I originally discussed Musketeering in this post.

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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!

  • Musketeering Makes Problems Intractable

    Musketeering Makes Problems Intractable

    Musketeering is lumping multiple difficult problems together to present a giant, intractable, disaster.

    The name comes from the famous slogan: All for one, and one for all!  Each musketeer supports the group, and the group supports each musketeer.  When multiple problems form as one, they become impossible to defeat.

    Most developers have faced a classic Three Musketeer problem with legacy code:

    1. The code is full of bugs
    2. Unit testing is nearly impossible
    3. Touching anything can have unknown side effects

    Each of these issues are fixable on their own, together they bring development to a halt.

    Why can’t you fix the bugs?  Because testing is nearly impossible and everything you touch has side effects.

    Why can’t you write tests?  Because the code is tightly coupled, which produces side effects.  Also, it is full of bugs so we don’t know what the correct functionality is.

    Why can’t you reduce side effects?  Because the code is buggy and there are no tests.  If you can’t separate the concerns, you can’t make progress.

  • The Never Rewrite Podcast, Episode Seventy-Three, The Politics of Delivering Trivial Changes

    The Never Rewrite Podcast, Episode Seventy-Three, The Politics of Delivering Trivial Changes

    Isaac and I discuss the philosophy of continuous iteration in software development, emphasizing the importance of making small, incremental changes rather than large, risky updates. We explore the challenges of communicating the value of these trivial changes to non-technical stakeholders and the benefits of refactoring code for future development. The discussion also highlights the significance of storytelling in conveying the purpose and impact of these changes to a broader audience.

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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 Never Rewrite Podcast, Episode Seventy-Two, Perfectionism in Programming

    The Never Rewrite Podcast, Episode Seventy-Two, Perfectionism in Programming

    I missed this week’s episode due to a scheduling conflict and the ever capable Dustin Rea filled in! Isaac and Dustin Rea discuss the impact of perfectionism in programming, particularly how it can hinder project success. They explore the importance of launching minimum viable products (MVPs) to validate ideas in the market, the challenges of managing change in production software, and the balance between perfectionism and practicality. The discussion also highlights the significance of team dynamics and customer empathy in software development, as well as lessons learned from scaling and responding to customer demands.

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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!

  • Understanding Churn Rate For Subscription SaaS Developers

    Understanding Churn Rate For Subscription SaaS Developers

    Churn Rate is one of the most important metrics for a Subscription based SaaS.  Churn is the term for a customer not renewing their subscription and ceasing to be a customer.  The Churn Rate is the percentage of customers you lose over a year.

    Ie – if you had 100 customers paying for a subscription at the start of the year, and 95 of them renewed their subscription, your churn rate would be 5%.

    Because the rate is based on existing subscribers, it can only be between 0% (everyone renewed) and 100% (no one renewed).  Churn is a key piece of Net Dollar Retention, another important metric for SaaS developers to understand.

    Churn Rate is especially important and simple for developers at SaaS companies with subscription models. Anyone who doesn’t renew their subscription has churned.

    What is a good churn rate?

    Churn rates differ based on your market and customer type.  For example, small business churns at much higher rates than enterprise.  See this article for an depth discussion.

    The 2 most important numbers:

    1. The average churn rate is 13% per year
    2. Sustainable Growth requires a churn rate below 8%/year

    The higher your churn rate, the harder it is to grow, or even tread water.

    How can developers reduce churn?

    Customers churn for all kinds of reasons that developers can’t impact.  Smaller customers go out of business; enterprise customers have internal politics.

    There are two places where developers have the greatest impact:

    The First 90 Days

    The first 90 days are your chance to provide value to your customers.  If customers don’t get value in the first 90 days they lose interest and try something else. 

    This isn’t the time to push for long term value, it is critical that your UI guide customers to small, quick wins.

    For developers, that means you need to work on two experiences:

    1. Importing data.  The process needs to be easy and fast.
    2. Reports.  Customers need to see the value.

    Bugs and Performance Over Time

    If you make it past the first 90 days, congratulations, your customer is likely to lock in to an annual subscription.  The 30 days before renewal, however, are not the time when a customer decides to churn.

    Long term customers churn because they aren’t getting value anymore, the platform is slow, or they hit bugs.  Circumstances change, when customers are no longer getting value from your service, there’s nothing to do but wish them luck as you wave goodbye.

    Is your platform fast and responsive?  Does it get slower over time? These are developer concerns!

    Do your customers hit bugs?  That’s a developer concern!  Each bug increases the odds that a customer churns instead of renewing.

    Conclusion

    For subscription based SaaS, Churn is a simple top level metric.  Higher churn means slower growth or even negative growth.

    The two key areas are the first 90 days, and long term performance and bugs.

    Make it easy to get started and see value; keep the customer experience from degrading over time.

    Last, remember that a lot of churn has nothing to do with your SaaS or your work as a developer!

  • Talk From StaffPlus NYC 2024

    Talk From StaffPlus NYC 2024

    I spoke about business strategy at this year’s StaffPlus NYC.

    If you’ve ever been paralyzed trying to decide which projects fit with your company’s strategy, or how to even identify your company’s strategy, this talk is for you!

    I cover the three main types of business strategy, how to learn which strategy your company is pursuing, and how to discuss projects through the lens of strategy. Learn how to identify projects with clear value that do not align with strategy; and how to discuss the problem with stakeholders.

    The talk is now online, free registration required:

    Focus on project value using businesses strategy

    And yes, the videographer goofed the spelling of my name. 🙂

  • The Never Rewrite Podcast, Episode Seventy-One, Are Ignorable Errors Still “Errors”?

    The Never Rewrite Podcast, Episode Seventy-One, Are Ignorable Errors Still “Errors”?

    Isaac and I ponder the question: If you intend to ignore an error in your logs, is it still an error? We roam through the implications of ignoring errors, the importance of proactive log management, the differe between true errors and warnings, and telemetry in alerting. If your logs are so noisy that it isn’t obvious when something goes wrong, this is the episode for you!

    Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, 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!