Sherman On Software

Sherman On Software Latest

  • The Never Rewrite Podcast, Episode Forty-Four, Do More With Less

    The Never Rewrite Podcast, Episode Forty-Four, Do More With Less

    Jeffrey and Isaac discuss the concept of ‘doing more with less.’ They explore the initial visceral reaction to this idea and highlight the importance of doing less of things that don’t matter. The impact of layoffs and the need to work smarter, not harder, are also discussed. The hosts emphasize the value of having honest discussions and creating a culture of transparency. They caution against burnout and advocate for trimming the fat responsibly. The episode concludes with a reminder to acknowledge mistakes and continuously learn.

    Takeaways

    • Focus on doing less of things that don’t matter instead of trying to do more with less.
    • Layoffs can have a significant impact on workload and employee morale, leading to burnout and a potential death spiral.
    • Work smarter, not harder, by finding ways to be more efficient and effective.
    • Create a culture of honesty and transparency to address challenges and make necessary changes.
    • Trim the fat responsibly by evaluating and adjusting projects and resources.
    • Acknowledge mistakes and learn from them to improve future decision-making.

    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 Grand Reveal Violates The SaaS Business Model

    The Grand Reveal Violates The SaaS Business Model

    Apple is legendary for the Grand Reveal.  Steve Jobs would say “Just one more thing” and then reveal an entirely new category of device or software.  It was amazing theatrics, shot Apple into the stratosphere, and cemented The Grand Reveal as a technology marketing tactic.

    But for a SaaS The Grand Reveal violates a key principal: customers always have the latest software.  Holding back months of development and new features in order to create an exciting reveal breaks that promise.

    Anytime you’re considering holding back a feature to create buzz ask yourself, does this delay help my existing customers?  You have customers that have already trusted you by buying subscriptions in exchange for the latest software.  Is it fair to hold back, to devalue the service, in order to market to new customers?

    Of course not!

    As a SaaS you’ve promised customers that they will always have the latest software.  Holding back breaks your promise.  Never hold back from your existing customers to market to new ones.  

    Always be releasing!

  • The Never Rewrite Podcast, Episode Forty-Three, Rewriting in the Age of AI

    The Never Rewrite Podcast, Episode Forty-Three, Rewriting in the Age of AI

    Jeffrey and Isaac discuss their stance on ‘never rewriting’ given the possibility of AI making rewriting faster, cheaper, and less risky. They explore the limitations of current AI capabilities and the potential benefits of AI-assisted refactoring. The conversation delves into the idea of using AI to write tests and improve code quality. They also discuss the challenges and opportunities of AI in language switching and high-performance code optimization. Overall, the episode highlights the evolving role of AI in the rewriting process and the potential impact it may have on software development in the future.

    Takeaways:

    • AI is not yet ready for code rewriting, but it has the potential to assist in the process.
    • AI can be used to write tests and improve code quality, but human supervision is crucial for effective results.
    • AI can help understand code better when provided with business context and documentation.
    • AI may play a significant role in language switching and high-performance code optimization in the future.

    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 Forty-Two, Iteration as a Defense From Micromanagement

    The Never Rewrite Podcast, Episode Forty-Two, Iteration as a Defense From Micromanagement

    Jeffrey and Isaac discuss how iteration can be a defense against micromanagement. They explore the reasons behind micromanagement, such as a lack of progress and fear, and how iteration provides observability and reassurance to managers. They emphasize the importance of breaking down nebulous projects into smaller deliverables and providing checkpoints to show progress.

    Takeaways

    • Iteration provides observability and reassurance to managers, reducing the need for micromanagement.
    • Breaking down nebulous projects into smaller deliverables helps show progress and alleviate fears.

    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 Forty-One, Rewrites from a Manager’s Perspective with Ryan Cowan

    The Never Rewrite Podcast, Episode Forty-One, Rewrites from a Manager’s Perspective with Ryan Cowan

    In this episode, Isaac Askew interviews Ryan Cowan, a software engineering manager, about the perspective of managers on rewrites. They discuss the challenges of placating individual engineers who want to rewrite code, the role of managers in supporting engineers’ ideas, and the frequency and success of large rewrites. Ryan shares a case study of data engineers rewriting a data pipeline and highlights the importance of understanding the root cause of concerns before deciding on a rewrite. They also discuss the difference between refactoring and rewriting and the expectations engineers have from their managers.

    Takeaways:

    • Managers play a crucial role in supporting engineers’ ideas for rewrites and refactors.
    • Large rewrites are infrequent and often require significant buy-in from senior leadership.
    • The distinction between refactoring and rewriting is important, with refactoring being more focused on improving existing code and rewriting involving significant changes to the entire system.

    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!

  • How Understanding Business Strategy Helps Developers Prioritize Projects

    How Understanding Business Strategy Helps Developers Prioritize Projects

    Understanding your company’s business strategy will help you battle analysis paralysis to find the right projects for your org.

    In my latest article at leaddev.com you will learn about the three types of business strategies, how to learn which one your company is pursuing, and how to apply them to your work to ensure that all of your projects add value.

    Would you like to hear more about understanding business concepts and metrics for developers? I think this is an important and under represented topic; I’d love to hear your feedback!

  • The Never Rewrite Podcast, Episode Forty, Convincing Emotionally-Committed Colleagues That A Rewrite Is Not Worth It

    The Never Rewrite Podcast, Episode Forty, Convincing Emotionally-Committed Colleagues That A Rewrite Is Not Worth It

    Isaac and Jeffrey provide strategies for working with colleagues who are emotionally committed to rewriting old and flawed code at their companies.

    Takeaways:

    • Validate the analysis and perspective of coworkers who are emotionally committed to doing a rewrite.
    • Consider the financial implications of a rewrite and align priorities with the business’s goals.
    • Communicate the rationale for not pursuing a rewrite and document the reasons for future reference.

    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!

  • Net Dollar Retention For SaaS Developers

    Net Dollar Retention For SaaS Developers

    Net Dollar Retention (NDR) is one of the core financial metrics for SaaS companies, and one where software developers have an outsized impact.  This article explains NDR and how software influences can drive the number down.  Finally, it discusses three areas for developers to focus on in order to bring the number up.  

    What is Net Dollar Retention?

    Net Dollar Retention is the rate that your existing customers continue to spend money with your company.  Renewals are flat, churn makes it go down, and expansion makes it go up.

    As a formula using AAR (Annual Recurring Revenue), it looks like this:

    ( [Renewed AAR] + [Expanded AAR] – [Churn] ) / [Previous AAR]

    Besides being a core metric, NDR is a key metric for companies considering going public.  Typically, a company going public needs an NDR over 107%, and ideally over 120%.

    Only existing customers affect this metric!  For Net Dollar Retention it doesn’t matter if you replace every customer that churns with ten new ones, your retention rate will be terrible.

    How Developers Impact Net Dollar Retention

    There are only two real levers with NDR: Increase spend and reduce churn; and there is little that developers can do that will directly increase customer spend.  

    The top 3 developer levers to reduce churn:

    1. Fix any bugs that corrupt or lose data
    2. Make the system more reliable
    3. Make the system faster

    Fix Any Bugs That Corrupt Or Lose Data

    This is the big one!

    Customers come to your service to get things done.  The more often they hit bugs, the faster they will churn.  Only developers can fix bugs and prevent data corruption.

    Make The System More Reliable

    Close second to data corruption is reliability.

    95% success rates mean that you should expect a daily job will fail at least once a month.  If customers don’t trust your system to work, they will sit and watch the process.  Usually by continually hitting refresh on your site.  This is a massive waste for your customer and makes your SaaS much more expensive.

    The less reliable your service is, the faster they will churn.  Reliability is more than just a developer problem, but developers will need to lead the architectural charge.

    Make The System Faster

    Speed is a distant third because it rarely impacts the value that customers get from your service.  Speed, especially UI speed, has a massive impact on the customer experience.

    Slow websites won’t make customers leave, but they will kill your net promoter score and leave them open to a switch.

    They don’t want to waste time staring at a blank screen waiting to render.  When the problem is inefficient code, it is something that only a developer can fix

    NDR is a Core Metric for SaaS Health

    NDR is a core metric for health, and a critical one for companies seriously looking at going public.  Developers can heavily influence the number by reducing churn.

    Fix bugs, improve stability and increase performance.

    Developers can push these levers and improve NDR; no one else in the company has that power!  Become a hero to your business, pay attention to NDR and how you can reduce churn!

  • The Never Rewrite Podcast, Episode Thirty-Nine, Project Risk with Jonathan Stark

    The Never Rewrite Podcast, Episode Thirty-Nine, Project Risk with Jonathan Stark

    Jonathan Stark joins as a guest to discuss the risks of hourly billing and the parallels between risk in a rewrite and in hourly billing. He explains how hourly billing puts all the risk on the client and leads to stressful relationships and arguments about hours and costs.

    Jonathan emphasizes the importance of trust and how it can be built through delivering on promises and becoming an authority in your field. He also provides strategies for pushing back against rewrites and making informed decisions based on cost and quality.

    In this conversation, Jonathan and Jeffrey discuss the importance of taking risks and understanding the business side of software development. They emphasize the need for developers to consider the financial risks their clients are taking on and the value they provide. They also highlight the benefits of speaking in terms of dollars and business outcomes rather than technical details.

    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!

  • Reduce Long Term Customer Churn From Data Growth

    Reduce Long Term Customer Churn From Data Growth

    Customer Relations are ever growing, a CRM must provide Management as well.  Punishing customers for loyalty is the inevitable consequence of not acknowledging and preparing for a long term relationship with your customers.  Destroying your customer’s long term experience increases churn and kills your net-dollar retention.

    Saving long term customers requires work and planning from the frontend to the persistence layer.

    Here is one strategy for each layer to help get you started:

    1. Frontend: Dashboards over pagination.
    2. Backend: Historical limits by default.  
    3. Persistence: Data partitioning.  

    Dashboards Over Pagination

    New customers can see all of their contacts on one page.  Same for their marketing campaigns, tags, and deals.  That changes very quickly for customers who are using your system.  When customers can’t see all of their data on a single page, the solution isn’t pagination, you need dashboards.

    When your customers go to their contacts, you could show them “Page 1 of 10”, or you could show them a dashboard with contact activity.  New contact counts, engagement rates, contacts who need a follow up.

    A pagination is about databases, it is a terrible interface for getting things done.  Make your CRM about management and workflows with dashboards.

    Historic Limits By Default

    Add sensible defaults to everything to limit the amount of data searched.  Default to showing the last 6 months or 1 year of a customer’s interactions.  Keep the older data accessible, but don’t waste the user’s time loading history.

    Put another way, how many extra seconds should you make customers wait to find out if a contact opened an email 3 years ago?  The correct answer is 0 seconds, and also 0 milliseconds; update your APIs accordingly.

    Data partitioning

    Event logs keep track of every email open, click, and website visit.  Because events rarely get deleted, these tables grow and grow with your customers.  Over time, the amount of data in the tables will cause queries to become slow.  The more successful your customers get, the worse your database problems become!

    Partitioning directs the database to create different logical tables based on a key while presenting a view of the combined table.  Events are date based making them great candidates for partitioning by month or year.  The previous tip, Historic Limits By Default, places an upper bound on the data in a table scan.

    Conclusion

    Customer data accumulates over time, especially in CRMs.  Keeping customers for years requires preventing your system from punishing them for accumulating data.  Failing to address the problems will destroy the customer’s experience, increase churn, and reduce your net-dollar retention.

    These three strategies will help you start thinking about data accumulation and how customer needs change over time.  Don’t throw away your loyal customers because your systems only consider the new user experience!