Menu

Sherman On Software.

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

Blog Posts

Rewrite Anti-Patterns: The Writeback

In iterative delivery, software designTags Publish Date97 ViewsLeave a comment jeffpsherman

In my post, The Strangler-Fig Pattern Has An Implementation Order; Outputs First, I mentioned The Writeback Anti-Pattern.  Turns out, that this anti-pattern hasn’t been named and described before; so I get to be first!

The Writeback Anti-Pattern is when a new Source Of Truth has to write data back to the legacy Source Of Truth because consumers are still getting data from the legacy source.

The Anti-Pattern allows you to pretend that the new system is indeed The Source Of Truth, and the legacy system has become an adapter.  This is a lie that lets teams declare success and get the new system into production.

The reality is that the new system is really just another bolt on to the old.  The new system now needs to transform all the inputs into the old format, creating tons of technical debt.  You have the data model you want, the data model you don’t want, and all the business logic in between.

Another way to explain it, is that the new system tried to do a strangler-fig backwards.  Instead of inserting itself between the old system’s outputs first, the new system intercepted the inputs.  For the strangler-fig pattern to work it needs to replace the outputs first, or both the inputs and outputs simultaneously.  Redirecting the inputs first leads to The Writeback.

The Never Rewrite Podcast, Episode One Hundred One: Relief vs. Cure

In podcastTags Publish Date67 ViewsLeave a comment jeffpsherman

Fix the problem, or mitigate the issue?

This week Isaac and I explore the complex trade-off between providing immediate relief versus investing time and resources into finding and fixing the underlying bug. Sometimes, fixing the bug is the wrong choice!

If you've ever agonized between fixing a bug, or just mitigating and moving on, 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: Detecting B.S. as a Non-Technical Founder

In podcastTags Publish Date112 ViewsLeave a comment jeffpsherman

"I'm not technical, but I think the developers I've hired are BSing me. How can I tell?"

This is often the first question Dustin and Isaac get when talking to potential clients. In this episode we work through issues with trust, communication, and how iterative development encourages both. Dustin reveals his framework for keeping communication open and identifing red flags in developer behavior.

If you've ever wondered what developers were doing, but were afraid to ask, 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 Strangler-Fig Pattern Has An Implementation Order; Outputs First

In iterative delivery, software designPublish Date104 Views1 Comment jeffpsherman

The Strangler-Fig is a critical refactoring tool.  The implementation sounds easy: wrap the existing code with the strangler, and replace the references over time.  This glosses over an important implementation detail - there’s an order to wrapping code: The outputs have to go before the inputs.

Strangler-Fig Examples Are Single Step

Oftentimes you can fully wrap the strangler around the existing code in a single step.  For example, Amazon’s Elastic Load Balancer can be used as a Strangler.  It instantly proxies all requests to a service; and makes it easy to migrate routes to a new service over time.

Systems with Multiple Outputs Need Multiple Stranglers

That works great for simple architectures with a single entrance and exit.  But what about something more complicated?  What if your system has a RESTful interface for data inputs and then publishes events onto Kafka?

Because the system has one input and two outputs, a single strangler like ELB is insufficient.

This system requires 2 different strangler-fig implementations.  An ELB, or web proxy, to handle RESTful communication, and kafka to proxy the communications from the service to kafka.

Even in an ideal world, where you can put the proxies into place with just simple config changes, this is a two step process.  More realistically, there will be weeks or months between setting up the first strangler, and the second.

The Partial Strangle Limits Options

Remember, the goal of the Strangler-Fig pattern is to squeeze out the original system over time.

A partial strangle limits your options.  

Doing ELB first lets you redirect RESTful inputs and outputs, but won’t populate the kafka stream.  This will break your system if you attempt to migrate any endpoints.  The Writeback anti-pattern, where the new system will write to the original system for the benefit of downstream listeners, is a common solution.

Putting the first strangler around the Kafka connection won’t break anything, and creates limited opportunity for migration.  Any messages that can be generated outside of the REST inputs can be migrated in this state.

For Complex Systems, Strangle The Outputs First

The Strangler-Fig pattern should be in every developer’s toolbox; there is nothing better for reducing risk during refactors.  If you have a complicated system, with more than one type of output, you will need multiple stranglers, and the order of application is critical.  Apply the stranglers to pure outputs first, input/output groups second, and pure inputs last.

Applying the stranglers in the wrong order will lead you to implement anti-patterns like The Writeback.  Far from making the transition easier and lower risk, the anti-patterns will make your work harder and riskier.

The Never Rewrite Podcast, Episode Ninety-Nine, DOGE Pt. 2: Government Rewrites with Guest Dan Hon

In podcastTags Publish Date70 ViewsLeave a comment jeffpsherman

Guest Dan Hon joins us to discusses the complexities of rewriting government software. Dan discusses the importance of understanding legacy systems, the role of ideology in software development, and the need for transparency and user-centered design. We also touch on government specific challenges that come with modernization of government services.

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 Ninety-Eight, DOGE’s Social Security Rewrite – Killing Americans to Save Money

In podcastTags Publish Date67 ViewsLeave a comment jeffpsherman

In my head, Never Rewrite, would be a completely apolitical show. How could the esoteric world of software projects ever intersect with politics?

I also never imagined DOGE's proposed rewrite of the Social Security system.

This week Isaac and I will work through the motivations, the challenges, and the role of AI in the rewrite. We will make predictions about the rewrite and how it will impact millions of Americans who rely on Social Security.

The cost of software mistakes is usually measured in dollars, these bugs will be measured with dead Americans.

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!

Real Life Testing In Production – Hotel Opening Disaster

In Algorithms In Real Life, iterative deliveryPublish Date85 ViewsLeave a comment jeffpsherman

This past week I stayed at a brand new resort hotel during opening week.  Opening week was a major disaster for the hotel, culminating with them giving away free alcoholic drinks to all guests.  For a week.

This post isn’t about all of the problems, it is about testing in production, and how much worse things could have been.  You see, the resort will eventually be 9 buildings, and they opened with 3.  As a firm believer in iteration I commend them because their opening would have been so much worse if they waited.

Eventually, the resort will be nine 4-story buildings in a U shape around a water park.  3 buildings were complete and receiving guests, the exteriors of 3 were complete, and 3 were being constructed.  Too late to learn any architectural lessons from the early guests, but not too early to learn a lot about the hotel’s operations.

First up - you need maintenance staff on site, because our first room had no hot water.  Maybe we were the first guests, maybe the system was installed wrong and broke.  Whatever the reason, there was no hot water, and no one who could diagnose and fix the issue.

You could have someone walk through with a checklist to test for things like hot water.  Or you could let your customers do it!  You could have maintenance staff on site, or you could literally file a ticket and wait for someone to show up and fix the problem.

The hotel wasn’t full, so we were moved to another room.  Another new room!

This one had no cold water in the bathroom sink.  Fortunately I could debug this issue!  The shutoff valve was closed; I opened it.  Yes, I flipped a switch to turn on a feature.

Another opening week oops - the hotel had purchased cone coffee makers and basket coffee filters.

But the ultimate config issue wasn't no hot water, or no cold water, or the wrong shaped coffee filters.  The ultimate config issue was no liquor license.  At a resort hotel.  For over a week.  They had a fully stocked bar, 2 bar tenders, and 4 wait staff.  But, no liquor license, means no alcohol sales.  They resolved the “alcohol permission issue” by giving it away.

All of these issues would have been so much worse with 3 times more guests.  They could have caught the quality issues with better testing.  They could have avoided giving away thousands in alcohol by waiting until they were ready.  There were many, many ways the hotel could have opened better.

But at least they iterated!  By opening with ⅓ of their rooms available, they were able to limit the fallout from testing in production.

SaaS Code Does Not Have a Final State

In crm, iterative deliveryTags Publish Date89 ViewsLeave a comment jeffpsherman

I was making a diplomatic comment about some software I was refactoring, “Regardless of the original programmer’s vision, the original code doesn’t work with the final state.”  I realized that my version of the code won’t be the final state either.  When you work in SaaS, code doesn’t have a final state.

SaaS code has history; it was written to solve a problem.  It may have evolved to solve the problem better, it may have evolved because the problem changed.


SaaS code has a present; it is what it is.  It solves a problem for some customers.  The code might be amazing, but frustrates customers because the problem has changed.  The code could be terrible but delights customers because it perfectly solves a static problem.

The code may have a future.  The problem can change, the implementation can change.

What SaaS code doesn’t have is a final state.  Until you delete it, you can never look at a piece of code and say that won’t be changed again.

Don’t make the mistake of thinking that once you refactor some code, the code will be in its final state.  The Service in SaaS will change over time, your code will change with it.

The Never Rewrite Podcast, Episode Ninety-Seven, Fulfilling Friday – A Tattoo Scam?

In podcastTags Publish Date51 ViewsLeave a comment jeffpsherman

Isaac's plan for a full arm sleave gains the attention of a famous tattoo artist. He just needs to act quickly and send money to secure the appointment…

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!

Sherman’s Law of Doomed Software Projects

In dev teams, iterative delivery, software designPublish Date132 ViewsLeave a comment jeffpsherman

Sherman’s Law of Doomed Software Projects - Software projects with the word “Next” or “New” in the name are doomed.

Sherman’s Law only applies to the internal name used by the people working on the software itself.  Names used in marketing or external communication don’t count.

Projects with the word “Next” in the title are doomed because no one wants the next version of your software.  Paying customers aren’t paying today because of the promise of a Next generation of the software.  Internal customers want software that helps them do their job today.  They are using the software today, because it solves a problem today.

Could there be future customers out there who have the problem your current software solves, but who will only buy if you release the next generation?  Sure, but if they’re willing to wait the problem isn’t that pressing and they probably won’t buy the next generation either.

Projects with the word “New” in the title are doomed because new is temporary and muddles project goals.  The new version starts off with clear goals and business value, but time is the enemy.  Whatever gets released is new, regardless of the goals and value in the final product.

If “next” and “new” are names for doomed projects, what names can you use?

You’ve got an existing product or service, and you need to do major work on it.  At the end, you’ll have the “next” generation, or “new” version of the product or service.  Speak to the reason you need to do the work.

If you discover that your software is fundamentally insecure, you don’t need a “Next Generation” project, you need “Maximum Security”.  If your system is slow, don’t start a “New” version that is faster, you need project “Lightspeed”.

I once wrote a piece of software named Polaris.  When the time came for major work, which name would focus the team and drive alignment better - Next Generation Polaris, or Maximum Security Polaris?  New Polaris, or Lightspeed Polaris?

Don’t doom your project, don’t use “Next” or “New”!

Older Posts
Newer Posts

Site Footer