Menu

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

Author: jeffpsherman

How I Will Talk You Out Of A Rewrite

In dev teams, iterative deliveryTags , Publish Date52 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 Date49 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 Date37 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 Date34 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 Date31 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 Date26 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!

The Never Rewrite Podcast, Episode One Hundred Thirty-Five: Is Changing an ERP System a Rewrite? ft. Sophia Rosa

In podcastTags Publish Date19 ViewsLeave a comment jeffpsherman

For companies that use an ERP, it is one of their core pieces of software. When a business decides to change ERP vendors, is that a rewrite? In this episode, Sophia Rosa, a project and organizational change manager, tackles the question of rewrites and walks us through the complexities of changing an ERP system. We go deep and learn that changing the software is just the obvious part of process.

If you've ever wondered what it would take to change an ERP and have it go well, 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-Four: A Stream of Consciousness Chat on AI, Tech, & Layoffs

In podcastTags Publish Date20 ViewsLeave a comment jeffpsherman

I had to miss this episode, thankfully Thomas Morris was available to fill in with a fun stream-of-consciousness style chat on AI, Tech, and Layoffs.

If you've ever wondered what it would be like if Isaac replaced me as co-host, 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-Three: The Consequences of Having Multiple Sources of Truth

In podcastTags Publish Date100 ViewsLeave a comment jeffpsherman

It is called the source of truth because it is the single, verifiable, source of truth. But what if you had 2, independent, sources of truth? Would that be twice as truthy? In this humorous episode, Isaac and I discuss a real instance of a market data system with multiple sources of truth.

If you've ever wondered if financial software is written by world class experts, 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-Two: A Thankful Thanksgiving Episode

In podcastTags Publish Date36 ViewsLeave a comment jeffpsherman

Happy Thanksgiving everybody!

If you want to get into the holiday spirit with some thanks, 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
Newer Posts

Site Footer