Menu

Sherman On Software.

When your SaaS Scaleup can't scale, I can help

Blog Posts

The Never Rewrite Podcast, Episode One Hundred Forty-One: How Rewrites Create Accountability Black Holes

In podcastTags Publish Date4 ViewsLeave a comment jeffpsherman

What happens to new bugs in a system being rewritten? Do they get fixed in both systems, just the new system, or neither systems? In this episode Isaac Askew and I explore how rewrites create accountability black holes that encourage bugs to linger.

If you have ever wondered why annoying, but simple, bugs don't get fixed, this is the episode for you!

Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app.

Have a tricky problem that you think requires a rewrite of your software? Join as a guest on our podcast and we’ll talk you out of it.

Want some custom advice? Book a 2-on-1 call with Isaac and me today!

The Never Rewrite Podcast, Episode One Hundred Forty: Evolving Past Boomer AI

In podcastTags Publish Date6 ViewsLeave a comment jeffpsherman

AI is great for coding! How is it doing outside of coding? In this episode Isaac and Dustin dig into AI's impact on legacy system development, team dynamics, and other human factors beyond the code.

If you've been wondering how AI is changing legacy development, 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 Roadmap to Hell Is Written In Features

In iterative deliveryPublish Date7 ViewsLeave a comment jeffpsherman

The road to hell is paved with good intentions; the roadmap is written in features.

The Road To Hell Is Paved With Good Intentions points to the common disconnect between someone’s intent, and the result of their actions.  Good intentions, and good actions, do not guarantee good outcomes.

Roadmapping features has the same disconnect between intent and results.  Good intentions, and good features, do not guarantee good outcomes.

Each feature makes sense, and is good by itself.

The problem is that the goal isn’t a feature, a whole series of features, or even projects.  The goal is the outcome.  Roadmaps full of features don’t track the progress towards an outcome, they track progress on features.

Roadmaps based on features present a linear path.  Each feature unlocks the next.  This, then that, and then that, until the project is complete.

Customer feedback isn’t baked into the process.  Will all of the good features lead to good results?  Probably not!

The opposite of roadmapping features, is roadmapping outcomes.  This requires getting clear on where things are, where they need to end up, and the mechanisms that drive change.

The only feature that comes out of an outcome based roadmap is the first one.  The first attempt to change the system.  After that?  Depends on the outcome of the feature!

Outcome based roadmaps are built on mechanisms that can drive change, and feedback loops.  The features are unknown because the impact of each feature is unknown.  

A roadmap built of features is like a road to hell, paved with good intentions.

The Never Rewrite Podcast, Episode One Hundred Thirty-Nine: A Failure of the Imagination ft. Mark Mandau

In podcastTags Publish Date12 ViewsLeave a comment jeffpsherman

Are rewrites a failure of the imagination? Are they the inevitable consequence of deferred maintaince? Is it possible a rewrite to succeed in such a way that it validates the choices that led to a rewrite? Mark Mandau rejoins Isaac and me to discuss how managers and leaders look at the question of rewrites.

If you've ever wondered how managers and leadership evaluate rewrites, 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!

How I Will Talk You Out Of A Rewrite

In dev teams, iterative deliveryTags , Publish Date5 ViewsLeave a comment jeffpsherman

If you come to me saying “we need a rewrite”, I will run you through a lot of “why” questions to discover if you actually need a rewrite.  I am basically trying to answer these three questions:

  1. What will the new system do differently?
  2. Why can’t you do that in the current system?
  3. Why can’t you build the new things separately?

Answering these questions yourself will help you think through whether you really need to rewrite your existing system.

Let’s examine each more closely.

What Will The New System Do Differently

What will be different about the new system?

For this exercise you have to ignore code quality, bugs, and developer happiness.  Those are all important, but corporate reality hasn’t changed.  The same forces that resulted in low quality code, endless bugs, and developer unhappiness are still there.  A rewrite might get you temporary relief, but over the long term, the same negative forces will be at work on the new system.

So, what is different about the new system?  The differences could be technical, like a new programming language, framework, or architecture.  Maybe you need to support a new line of business and the existing system can’t stretch to cover the needs.

Get clear on what will be different, and write it down.  These are your New Things.

Why Can’t You Do It In The Current System

Now that you are clear on what New Things you need, why can’t you build the New Things into the existing system?

We are still putting aside issues like the existing code quality, bugs, and developer happiness.  If those forces are all that is stopping you from doing the new work in the existing system, I have bad news, those forces will wreck the new system as well.  You don’t need new software, you need to change how you write software.  Stop now, while you only have one impossible system to maintain.

Other than the forces that cause you to write bad software, why you can’t use the current system.  Get clear.  Write it down.  These are your Forcing Functions.

Why Can’t You Build The New Things Separately?

At this point we know what the New Things are and we know the Forcing Functions that prevent you from extending the current system.  Why can’t the New Things live alongside the existing system?

A rewrite requires rewriting all of your existing system.  Building New Things in a new system because of Forcing Functions, only requires building the New Things.  Why can’t you do that?

By this point office politics are out.  Office politics can’t overcome Forcing Functions.

Quality and bugs are also out, because there is no existing code to consider.

Get clear.  Write it down.  This is your Reasoning.

Now, take your Reasoning, backed by the Forcing Functions, and you have explained how getting the New Things requires a rewrite.  If your Reasoning can convince your coworkers, then I’m sorry, you do actually need a rewrite.  

If not, it is time to talk about alternatives.

What Happens After I Talk You Out Of A Rewrite

Most rewrites are driven by development culture issues, not the software itself.  This brings us back to code quality, bugs, and developer happiness.  A rewrite won’t fix any of those issues.

The good news is that you can fix all of them without a rewrite.  Even better news is that fixing them will only take about as much effort as you think a rewrite would take.  The bad news is that your culture is pushing against making the fixes.

Take it one step at a time, and keep delivering.

What Does This Button Do?

In software designTags Publish Date10 ViewsLeave a comment jeffpsherman

I regularly point out problems with physical buttons.  Physical buttons help visualize the conceptual problems behind buttons on websites, without the distractions of technology.

Today’s example comes courtesy of a minivan I rented in Texas.  As a car, it was fine.  As a UX platform, it was full of reused visual elements with different actions.

As an example, here is a closeup of the door panel.

This looks like pretty standard door stuff.  Two doors, two handles, two buttons.

The front set (right side) performs like most other car door handles.

Sometimes the door button will toggle lock state, sometimes it only locks the doors.  Likewise, some door handles will automatically unlock the car, and others will only allow you to open the door if the car is unlocked.

Pretty standard stuff.

The rear set of controls is for the minivan’s sliding door.  They work entirely differently.

The sliding door is automatic.  The handle and the button both engage the mechanism.  

If you pull the handle, you should then let go, because the car door will open itself.  The handle is also a toggle, if the door is open and you pull the handle, the door will close.  At no time should you use human muscle to open or close the door.  This is different from the front door, which requires human muscle to both open and close.

The rear button is also a door open and close toggle.  While the front button performs an idempotent “lock only” action, pressing the rear button will always change the state of the door.

Same Element, Multiple Actions

There are 2 buttons that look the same, are placed the same, and do different things.  The 2 handles also look the same, are placed the same and do different things.

The sliding door handle is redundant, it does the same thing as the button.  It also introduces a major point of failure because it invites humans to use muscle against a self powered mechanism.  To illustrate the fragility, I took a minivan taxi home after leaving Texas and the driver shouted not to touch the door handle.  He explained that people pull hard on the handle and break the door mechanism.

Design Failures And Standard Resolutions

In summary there are 2 design failures here:

  1. Using the same visual element to do different actions.  When buttons and handles do different things, they should look different.
  2. Using a design that encourages users to do the wrong thing.  All door handles, except minivan sliding doors, are meant to open doors by pulling.  Since the sliding door doesn’t want people to pull hard, it shouldn’t use a standard door handle.

Pushing My Buttons

After a few mistakes I stopped opening the sliding door when I meant to lock the car.  I stopped using the sliding door handle entirely.  I quickly learned the UX, but I never escaped the extra friction.  My eyes would still lock onto the buttons and I would have to think about what they did before taking action.

Like the minivan, UIs are littered with inconsistent buttons, multiple ways to do the same thing, and the ability to do “the wrong thing” because your expectations don’t match what the designer was thinking.  Users will learn the system, but the extra friction will never disappear.

The Never Rewrite Podcast, Episode One Hundred Thirty-Eight: The MVP Worked. Do We Rewrite It To Scale?

In podcastTags Publish Date13 ViewsLeave a comment jeffpsherman

You've made an MVP and it can't handle its own success. Do you rewrite it? And does starting over to build something you know is useful qualify as a rewrite?

If you've ever had code crushed by success, 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!

ShermanOnSoftware 2025 Year In Review

In UncategorizedPublish Date6 ViewsLeave a comment jeffpsherman

I set ambitious goals for 2025. 

I was doing well, then my plans changed.

Original Goals

My goal was to write a blog post every Monday and Wednesday; and then do a Podcast episode every Friday.  I gave myself a little slack, I only wanted to write 100 blog posts.

In the end, Isaac and I published 52 podcast episodes.  I also wrote 34 blog posts and 19,500 words.

This wasn’t a case of running out of steam, I was on pace until Isaac and I decided to write a book.

The Rewrite Trap

In March, Isaac and I decided to write a book about rewrites.  You can pre-order it here, I guarantee it will be the greatest book on the fallacy of software rewrites ever written.  It will also be the first book ever written on the subject.

Right now the book is about 100 pages and 18,000 words.  The first draft is complete - we have said everything we intend to say.  Now we are working to make our arguments persuasive and well written.

Total Words

I didn’t have a total word goal for 2025.  In 2024 I wrote 23,000 words and 44 posts.  In 2025 I wrote 19,500 words on the blog, and at least 9,000 more on the book, for a total of 28,500.

I wrote 23% fewer posts last year, but I also wrote 24% more words.

Conferences

I hoped to speak at 1 conference in 2025, and it didn’t happen.  I did write 6 speaking proposals; none were accepted.

Unlike blogging, podcasting, and writing, this goal isn’t entirely in my control.  Going forward I will adjust my speaking goals accordingly.

Goals For 2026

With 2025 in the rear view mirror, what do I want to achieve in 2026?

  1. Another 52 episodes of Never Rewrite.  No change in the headline.  I do want to spend more effort getting guests on to talk about their experiences.
  2. 100 blog posts on ShermanOnSoftware, or 30,000 words.  I want to publish twice a week.  I was on target until deciding to write a book.  This year I am adjusting the goal to take the book into account.  I can write a lot of pieces, or I can write a lot of words.  I am also changing how I block out time for writing, and I am hopeful that stronger systems will enable me to be more consistent.
  3. Publishing The Rewrite Trap.  The book will probably be self published, but I am also committing to submitting book proposals to the 4-5 publishers who might publish it.  If it does get picked up by a publisher, it won’t be out in 2026, and that’s ok too.
  4. Speaking at 1 conference, or submitting at least 10 conference talks.  Unlike the first 3 goals, I can’t control whether I get booked to give a talk.  I can control how many submissions I make, so I will keep at it and keep revising talk ideas based on feedback.

I am intentionally not putting down goals for things I hope will happen next year like:

  • Book sales
  • Consulting jobs
  • Teaching classes about rewrite alternatives
  • Increasing podcast listeners
  • Increasing mailing list subscribers

I hope all of those things will happen, but I am not making them a priority.

Check back next year to see how things played out!

The Never Rewrite Podcast, Episode One Hundred Thirty-Seven: 2025 Year in Review

In podcastTags Publish Date11 ViewsLeave a comment jeffpsherman

Navel gazing time, how did Never Rewrite do in 2025? Isaac and I review our goals and accomplishments from the past year and discuss what 2026 has in store.

If you like year in review episodes, 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 Never Rewrite Podcast, Episode One Hundred Thirty-Six: Key Questions to Ask When Navigating Your Career

In podcastTags Publish Date9 ViewsLeave a comment jeffpsherman

Today is a great day to think about your career! Dustin Raie and I can't tell you what you should do; we can help you ask yourself questions. No matter what stage of you are in, getting the career you want takes effort on your part.

If you've got a career, 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!

Older Posts

Site Footer