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

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

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

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