Menu

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

Tag: TheeSeeShip

The Rewrite Release Fear

In iterative deliveryTags , , , Publish Date179 ViewsLeave a comment jeffpsherman

Release Fear is a common killer of rewrite projects.  

As a rewrite comes closer to release, higher ups will start taking an interest in the project.  These leaders won’t have context on the myriad discussions and compromises that went into the rewrite.  Instead, they focus exclusively on lost features.  Value creation gets ignored and the release gets blocked in the name of existing functionality.

Is the missing functionality important?  Do the features outweigh the value that the rewrite brings to customers?  The team doing the work decided that these were good tradeoffs.  Loss Aversion ensures that leaders only see what was left out.

Adding the missing functionality comes at the cost of time and the value of the rewrite.  As costs go up, each revision makes the fear worse.  I have seen multiple projects, years of programmer time, fail because they could not be released to production until they could prove that the release would be perfect.

The alternative is to TheeSeeShip.  When you have 2 versions of the code you can have a discussion about which one should be in production.  When there is only one version, there’s nothing to discuss.

TheeSeeShip to keep the stakes low and Release Fear won’t be a problem.

Smile And Dial CRM – Part 4 – As If By Magic

In crm, iterative deliveryTags Publish Date150 Views1 Comment jeffpsherman
Sherman On Software Logo

SmileAndDial CRM was built around the concept that people are nothing but a number.  Phone numbers were a fundamental constraint in the software; it was impossible to have a contact that didn’t have a number. 
With the introduction of TheeSeeShipping and months of Invisible Shipping SmileAndDial has been able to free themselves of this incremental constraint.  Through many iterative releases the company has slowly been transforming itself.  


The data model has gone from using Phone as a key in all tables.

To a normalized model with foreign keys that don’t carry extra meaning.

Changes were small.  They were low risk and had no customer impact.  There was little work in flight, and occasional priority shifts didn’t result in code rot.  Their slow accumulation removed a fundamental constraint that was built into the company’s founding principles.

Happy Ending?

SmileAndDial CRM is still the go to CRM for boiler rooms, pump and dumps, extended car warranties, and other outbound call center activities.


Now, as if by magic, they are also ready to help their customers expand and spam prospects with ads for bitcoin, blockchain technologies, and of course, male enhancement pills.


Thankfully this is a fable and we can pretend that this is a happy ending!

Smile And Dial CRM – Part 2 – Start TheeSeeShipping

In iterative deliveryTags Publish Date114 Views2 Comments jeffpsherman
Sherman On Software Logo


We know why SmileAndDial CRM needs to change their fundamental constraints We know why changing the data model is difficult.

In part 2, I’m going to show you how to TheeSeeShip these changes to release small, low risk, bits of functionality and avoid a high risk, high lag rewrite.

The First Release Series - Adding IDs

The first series of incremental releases is to add new columns to the existing tables.  The Contact table needs an auto-incrementing Id column that will eventually become the new, non-phone, primary key throughout the system.  All the other tables need an int ContactId column that is nullable for now.  

Because we are TheeSeeShipping, we are not making Id a primary key, allowing ContactId to be null, and not setting up any foreign relations.  We will do all of those things over time, but doing them all at once makes the changes large and risky.

Instead these changes are entirely additive.  The changes are also completely independent of each other, making it possible to update the schema one table at a time.  Whether this goes out in one release or 4, they are low risk changes.

Part 3 continues the process with Invisible Shipping. The process of TheeSeeShipping major changes in small, low risk, incremental steps

TheeSeeShip – The Opposite of a Rewrite

In iterative deliveryTags , Publish Date605 Views8 Comments jeffpsherman
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.

Site Footer