Blog Posts

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

Smile And Dial CRM – Part 1 – The problem with direct change

Sherman On Software Logo

Welcome back to SmileAndDial CRM’s journey to remove phone numbers as a fundamental constraint.  In the introduction I introduced SmileAndDial CRM, a loathsome service for boiler rooms, pump and dumps, extended car warranties, and other horrid outbound call centers needs.  SmileAndDial has a problem, all contacts need a phone number and they need to transition away from phone numbers to enable their customers to send spam.How fundamental are phone numbers?  Let’s begin with the data model and how it reinforces the constraint.

Phone Numbers As Primary Keys

As the data model leaves no doubt, to SmileAndDial, you are nothing but a number.
Phone number is the primary key used throughout the system.  The developers made an interesting trade off - in exchange for a bigint primary key, which doesn’t have great indexing, they got a system with no joins.

No Joins?

That’s right!  Because the phone number is the primary key, users can enter a phone number into any search field and the system can use it directly without having to join against the Contact table.

When was the last time I called a contact?
“Select max(Date) from Calls where phone = [phone]”

How much have we sold to a contact?
“Select sum(price) from Sales where phone = [phone]”

Few operations need to join back to the Contact table, which reduces code complexity.

What Happens If There’s No Phone?

Now we get to the crux of the constraint - nothing works without a phone number.

Simply updating the Contact creation logic to allow phoneless contacts won’t work.  The new contact can’t have notes or sales without a phone number.

In part 2, we will start TheeSeeShipping our way out of this mess.  By delivering incremental, iterative changes that we will reduce risk and increase customer value.

Smile And Dial CRM, A Fable About Transforming Fundamental Constraints

Sherman On Software

Data assumptions are baked into your CRM’s makeup and can seem impossible to change.  Email marketing requires contacts to have an email, because you can’t do email marketing without one.  Call center software requires prospects to have phone numbers so that agents can do outbound sales.

But what happens when your business needs to change and your fundamental constraints are no longer fundamental?  How do you change your core data model assumptions without starting over or freezing development?

SmileAndDial CRM has spent years positioning themselves as the go to CRM for boiler rooms, pump and dumps, extended car warranties, and other outbound call centers on the strength of their dialer integrations.  They’ve done well, making a quality product for horrible people.  But the FTC is cracking down on junk calls and putting their customers out of business.  They need to expand into email spamming and help support their horrid customers.  After all, keeping your customers out of jail massively extends Customer Lifetime Value.

This series will follow SmileAndDial on their journey to remove phone numbers as a fundamental constraint in their software.  

Part 1 - The problem with direct change
Part 2 - Start TheeSeeShipping
Part 3 - Invisible Shipping
Part 4 - Numberless Contacts appear as if by magic

The Never Rewrite Podcast, Episode Thirteen, Transitioning from Microservices to a Monolith with Josh Beckman

In episode 13 of the Never Rewrite podcast, Isaac Askew and I are joined by Josh Beckman to discuss why he led his team on a his journey from a monolith, to a service oriented architecture, and finally back to a monolith. This is a fascinating episode about transformations and the necessary groundwork needed to make it all possible.

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

Watch on YouTube

The Never Rewrite Podcast, Episode Eleven, You can’t Build To Spec

In episode 11 of the Never Rewrite podcast, Isaac Askew and I discuss the difference between software that satisfies a specification, and software that delivers client satisfaction. They're two distinct problems and we talk through how to reduce the risk of delivering one without the other.

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

Watch on YouTube

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

Site Footer