Sherman On Software Latest

  • Better In Every Way Is Impossible

    Better In Every Way Is Impossible

    A common tech fallacy is that legacy tech will go away if only you build a better version.  Make something “better in every way” and then you can get rid of the old version.

    When you own the software, you can force change.  But you can’t do it by making something better in every way.

    Once upon a time writing was only distributed on stone tablets and scrolls.  Later we invented books, the printing press, and the internet.  Each invention let us distribute writing wider with less cost.  Even though it is more expensive and less effective, legacy “writing distribution tech” is still with us; we still produce writing on stone tablets, scrolls, and books.

    When we first started distributing written ideas, the only way to get a copy was to find someone who had a copy, borrow it, and pay a scribe to copy it.  Later, we invented printing presses which let us mass produce copies.  Still later we created the internet which lets us produce infinite copies.  Yet legacy “copy creation tech” is still with us; scribes still copy manuscripts by hand.  We still have printing presses mass producing physical copies.

    Whatever your system, whatever your tech, there will always be something “better” about legacy technology.  Sometimes legacy tech is better just because the customer is already using it.

    Your new system may be amazing, you may see it as better in every way; remember that your customers have their own opinions and reasons.

  • The Never Rewrite Podcast, Episode 6, How Company Culture Makes Or Breaks Your Team

    In Episode 6 Isaac and I discuss the How Company Culture Makes Or Breaks Your Team. We talk through the good and bad, the winds of change, and some things you can do to protect or change the team from within.

    Available at Never Rewrite, Spotify and Apple Podcasts

  • Actions Over Objects

    Actions Over Objects

    After a few weeks, a customer’s first page of contacts will become static.  Same with tags, lists, and every other object that your CRM supports.  When the data on the first page becomes static, users stop seeing it entirely.

    Instead the first page becomes muscle memory on the way to your user’s real actions.

    How long do you make your customers wait to load a page of data objects that won’t even register in their minds?  How many extra hoops do they have to jump through to get to the actions they want to take?  How much slower is the process for your biggest customers?

    Customers log in to take actions, not objects.  Don’t waste their time showing data objects until you know enough context to show meaningful data.  

    Data scales, actions and attention don’t.  You can wage a constant fight to scale your UI, or you can choose Actions over Objects, and avoid the issue entirely.

  • The Never Rewrite Podcast, Episode 5, Perverse Incentives

    The Never Rewrite Podcast, Episode 5, Perverse Incentives

    In Episode 5 Isaac and I discuss the Perverse Incentives that push new hires, developers and managers to suggest Rewrites over Iterative Improvement.

    How perverse are the incentives behind a rewrite? Perverse enough to drive the developers and managers out of the company. If you’re an executive, you don’t want to miss this one!

    Available at Never Rewrite, Spotify and Apple Podcasts

  • TheeSeeShip – The Opposite of a Rewrite

    TheeSeeShip – The Opposite of a Rewrite

    I cohost a podcast devoted to the idea that starting over and rewriting your system is a mistake that will lead to failure.  But I have struggled with explaining the alternative, iterative replacement.

    One commenter summed it up as: Don’t rewrite, instead rewrite.

    I’m inventing a new term, TheeSeeShip, to highlight the difference.  Based off the Ship of Theseus, when you TheeSeeShip, you are iteratively replacing parts of the current system that are broken, don’t scale, or just aren’t useful anymore.

    A rewrite creates a second system, with the hope of one day becoming the sole system.  Until that day, you have the system you use, and an ever growing mass of untested work in progress.

    When you TheeSeeShip, there is only ever one system and everything will be in production the whole time.  Over time you’ll replace every line as you add and remove services, features, and scaling patterns.  Everything changes, but the system remains.

    The opposite of a Rewrite is to TheeSeeShip.  TheeSeeShipping is lower risk, provides more value to your customers, and boosts morale.  I’ll dig into why in the posts ahead.

  • The NeverRewrite Podcast, Episode 4, Nozomi

    The NeverRewrite Podcast, Episode 4, Nozomi

    Episode 4 of The NeverRewrite Podcast is available on your favorite podcast apps, or directly at https://www.neverrewrite.com/podcast/episode-four-nozomi

    For those of you who like video, we also started a YouTube Channel!

    In Episode 4, Isaac and I speak with special guests Nathan Keys and Colleen Grafton about our shared experience on the Nozomi project. In many ways Nozomi was the genesis of this podcast, it’s where I first started noticing the Rewrite Pattern, and where Isaac and I met.

  • Scaling like a Baker

    Scaling like a Baker

    When you’re baking at home, for a few people, you can usually double the recipe and it will come out fine.  

    Quadrupling the recipe, however, rarely works.  To get the same results you’ll need to adjust an ever growing list of variables.  The extra pans will impact the airflow. The extra mass will change the heat distribution and baking times.  As you scale, things like extra moisture will become  problems.

    Many SaaS Companies start off a lot like a baker working in a home kitchen.  You can usually double everything and it will come out fine.  Trying to quadruple the service introduces complex problems like concurrency, data loss, partial failures, and stale data.

    Just as the transition from home to industrial kitchens has sunk many food startups, the transition from startup to scaleup has sunk many SaaS companies.  If you can’t offer repeat customers consistency they won’t come back.

  • The NeverRewrite Podcast, Episode 3, Why you hate testing

    The NeverRewrite Podcast, Episode 3, Why you hate testing

    Isaac and I discuss the developer’s journey from testing ignorance through acceptance. Sometimes rewrites are the inevitable outcome of the vicious cycle where hard to test code results in a codebase with few tests, which makes changes difficult and risky, which limits the value of writing tests, which leads to developers hate testing.


    https://www.neverrewrite.com/podcast/episode-three-why-you-hate-testing

  • The C in CRM Grows Unbounded

    The C in CRM Grows Unbounded

    There’s no upper limit on the number of Contacts that customers will want to add to your CRM.  Until you can support billions of contacts, there’s always an argument that you should support more.

    On the other hand, Relationship and Management options are constrained by the choices you present to your users.  You can’t support everything and need to consider which options make sense for your CRM.  Every option adds complexity and cost to you; and cognitive load on your users.  Adding features often decreases value.

    When it comes to contacts, think about what scales.  For everything else, remember that people have limits.

  • NeverRewrite Episode 2 – Iterative Replacement

    In this episode, Isaac and I try to answer the question “What should you do if you Never Rewrite?”

    Listen today at https://www.neverrewrite.com/podcast/episode-two-iteratively-replace
    Or Subscribe at:

    Do you have a problem that requires a rewrite? Can’t find another solution? Don’t know where to begin?

    Contact Isaac and I and we can help talk you through it!