Sherman On Software Latest

  • What Does This Button Do?

    What Does This Button Do?

    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?

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

    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

    ShermanOnSoftware 2025 Year In Review

    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

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

    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

    The Never Rewrite Podcast, Episode One Hundred Thirty-Six: Key Questions to Ask When Navigating Your Career

    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

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

    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

    The Never Rewrite Podcast, Episode One Hundred Thirty-Four: A Stream of Consciousness Chat on AI, Tech, & Layoffs

    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

    The Never Rewrite Podcast, Episode One Hundred Thirty-Three: The Consequences of Having Multiple Sources of Truth

    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

    The Never Rewrite Podcast, Episode One Hundred Thirty-Two: A Thankful Thanksgiving Episode

    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!

  • The Never Rewrite Podcast, Episode One Hundred Thirty-One: Rewrites from a Product Perspective ft. Mark Mandau

    The Never Rewrite Podcast, Episode One Hundred Thirty-One: Rewrites from a Product Perspective ft. Mark Mandau

    For years Never Rewrite has chronicled rewrite disasters from the developer’s perspective. In this episode, for the first time, we are going to cover rewrites from a Product Perspective. Isaac and I are joined by product consultant Mark Mandau, to discuss how rewrites are perceived by product and the business.

    If you have been nodding along with us about rewrites, but wondering how non-developers feel, 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!