The Never Rewrite Podcast, Episode Ten, The Rewrite Cycle, What To Expect When Rewriting

In episode 10 of the Never Rewrite podcast, Isaac Askew and I discuss the phases that most rewrites go through. Rewrites have distinct up and down patterns; if you've never taken the ride the switches can feel sudden and confusing. Isaac and I explain the phases and take some of the mystery out of why rewrites follow the pattern.

Listen to it at NeverRewrite, Spotify, or Apple Podcasts.

Watch on YouTube

The Never Rewrite Podcast, Episode Eight, The Service to SaaS Transformation with Brian Begy

In Episode 8 of the Never Rewrite podcast, Isaac Askew and I discuss the process of transforming a Service Business into a SaaS with Brian Begy. What happens when a company wants to evolve from using software to run a service business, to offering software for others to run a service business?

We discuss many ways that won't work, and one path that leads to success.

Listen at NeverRewrite, Spotify or Apple Podcasts:

Better In Every Way Is Impossible

Sherman On Software Logo

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.

Actions Over Objects

Sherman On Software Logo

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

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

Sherman On Software Logo

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

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.

Site Footer