Sherman On Software

Sherman On Software Latest

  • The Never Rewrite Podcast, Episode Thirty-Eight, Maintenance Work as a Flight to Safety

    The Never Rewrite Podcast, Episode Thirty-Eight, Maintenance Work as a Flight to Safety

    Isaac and Jeffrey explore the significance of maintenance work for developers, stressing its strategic value during uncertain periods like layoffs. They share personal experiences, highlighting how tackling these tasks can lead to trust, new opportunities, and a more impactful role within a team.

    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 Thirty-Seven, Interview Insights – Changing the Game for Interviewers and Candidates

    The Never Rewrite Podcast, Episode Thirty-Seven, Interview Insights – Changing the Game for Interviewers and Candidates

    Isaac and Jeffrey dissect the flaws in the interviewing process and offer valuable insights for both interviewers and interviewees. They discuss the broken aspects of traditional interviews, highlight the importance of resume tailoring, and share anecdotes about handling past job experiences during interviews. The episode serves as a guide for interviewers to improve the hiring process and for candidates to enhance their chances by navigating the pitfalls and maximizing opportunities.

    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 Thirty-Six, Becoming an Expert in your Company’s Business

    The Never Rewrite Podcast, Episode Thirty-Six, Becoming an Expert in your Company’s Business

    Jeffrey and Isaac discuss why understanding how your company makes money can help you build products that solve the right problems.

    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!

  • Phase 1 is a Millstone not a Milestone

    Phase 1 is a Millstone not a Milestone

    Metaphorically, milestones are markers on your transformation from one state to another.  Millstones are useless, heavy, burdens that you can’t put down.

    Project plans that seek to set out project milestones often end up burdening themselves with millstones.  The mistake is confusing the transformation with the project.  Millstones track the journey, milestones track the destination.

    Things like “Phase 1” can’t be a milestone because there is no guarantee that completing Phase 1 means that you’ve made any progress towards your goal.  Yes, you worked hard and delivered a lot of code.  You’ve done the things you said you would do when you originally planned the project.  Can you objectively show that you’re closer to your destination?

    Milestones, by contrast, are objective, external, measures of progress.  “Customers can use a feature” is a milestone.  “First paying customer” is a milestone.  They are points you expect to cross during the transformation because they demonstrate progress.  You can declare that some milestones are irrelevant, you can set new milestones, but you can’t move the milestones themselves.

    Project based millstones like Phase 1 encourage movement and gaming to meet artificial deadlines.  Can’t complete a feature in time, just move it to Phase 2 and keep the project on track.  Phase 1 encourages wasteful death marches so that developers and project managers can report that the project is moving forward.

    You can put down your millstones wherever and whenever you want.  Makes no difference to anyone or anything other than the artificial constraints you put on your project.  Today is a great time to let go of the weight.

  • The Never Rewrite Podcast, Episode Thirty-Five, The Subtle Art of Refusing Meetings

    The Never Rewrite Podcast, Episode Thirty-Five, The Subtle Art of Refusing Meetings

    Jeffrey and Isaac discuss methods to clear out your recurring meetings and protect your time as new meetings get added to your calendar.

    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!

  • ShermanOnSoftware 2023 Year In Review

    ShermanOnSoftware 2023 Year In Review

    It’s the time of year to look back, reflect, and highlight some interesting pieces you might have missed.

    Also known as the self indulgent year in review post!

    By The Numbers

    In 2022 I set a personal goal of publishing twice a week, or at least 100 articles in 2023.  I published 65 different pieces, almost ⅔ of my goal!

    I published 34 Podcasts, 31 Articles, and wrote over 11,000 words.

    For 2024 I’m going to stretch further and shoot for 50 podcasts and 100 articles; for a combined schedule of 3 items/week.

    I’m also aiming for 6 published articles on other sites and 1 conference talk.

    Top 3 Articles Written in 2023

    Top 3 Most Popular Articles in 2023

    Thanks for reading!

  • The Never Rewrite Podcast, Episode Thirty-Four, (F*ck-Up Friday Series) Don’t Fix What Ain’t Broken

    The Never Rewrite Podcast, Episode Thirty-Four, (F*ck-Up Friday Series) Don’t Fix What Ain’t Broken

    Continuing our F*ck-Up Friday series, I share another humorous story where I went out of his way to fix functionality to match the name of its function…with expensive results.

    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 Thirty-Three, How to be a Terrible Teammate

    The Never Rewrite Podcast, Episode Thirty-Three, How to be a Terrible Teammate

    In this humorous holiday episode, Isaac and Jeffrey discuss ways to be the worst possible teammate; in ways that won’t get you immediately terminated by HR. If you didn’t make the naughty list this year and want to lock it in next time, this episode is 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!

  • Two Paths For Paying Down Tech Debt

    Two Paths For Paying Down Tech Debt

    In my last post I discussed two ways of making Tech Debt an expensive problem that gets fixed.  

    I was trying to show that a rewrite or major project requires proving that the problem is very large, and convincing leadership that you can solve it in a cost effective manner.  A key piece is that the problem must be large to justify fixing it.  Rewrites and projects encourage you to raise the stakes to create urgency and justify the costs.

    Iterative Delivery is about lowering the stakes.  The stakes are low, the urgency is low, and the costs are low.  You can “just do it” by adding a few hours onto your regular development cycle.  Instead of needing to convince leadership it would be strange to mention it all.  The stakes are too low to bother them at all.

    Here are the two paths as a flowchart:

    TheeSeeShipping, iterative delivery, brings results faster.  Choosing this path will have you paying down technical debt while rewrite plans are still being written.

    There is another major difference between the paths.  A rewrite requires you to complete the whole project before you can measure the impact.  You don’t get to know if your project was worthwhile after you have spent all the time and money.  Maximizing the stakes also maximizes the risk.

    Iterative delivery gives you unlimited opportunity to evaluate progress and change course.  Some changes will be worthwhile, some won’t, and you get a chance to access and correct after each change.  The stakes are low and so is the risk.

    Picking a rewrite over iterative delivery increases risk and delays results.

  • Tech Debt is a Big, But Not Expensive, Problem

    Tech Debt is a Big, But Not Expensive, Problem

    A common mistake among developers and line managers is to mistake Tech Debt as an Expensive, instead of a Big, Problem.  For tech debt to be an Expensive Problem the CTO and VPs of Development have to believe that the value the company will get from paying down tech debt is greater than the cost.

    Leadership doesn’t reject pitches for rewrites and other major initiatives to address tech debt because they don’t believe that Tech Debt is a Big Problem.  The initiatives get rejected because they don’t believe that the results will justify the cost.

    There are two ways to get around the Big vs Expensive problem.

    The first is to use data to prove that the problem is Expensive.  

    Find a way to measure the costs of tech debt: lost developer time spent fixing bugs, increased developer time building new features and above average customer churn.  Then, find a way to estimate how much better things will be after the big initiative.  Finally, estimate how long the transformation will take.  If you can credibly show that the improvements are greater than the costs, you should have no problem getting your initiative approved.  

    Remember though, that you’re estimating the value of the improvements and length of time.  Credibility is as much about leadership’s faith in your delivery as it is in the numbers.

    The second way to get around the Big vs Expensive problem is TheeSeeShipping, aka Iterative Delivery.  

    Make small improvements every release and show that the cost of the problem is shrinking over time.  Less time spent fixing bugs, faster feature development, maybe even a reduction in churn.  Demonstrate that Tech Debt is an Expensive Problem by fixing it and providing more value than cost.

    You’ll find that you won’t have any trouble getting approval, because you won’t need any approval at all.  You just need to start.