Menu

I help SaaS Companies retain whale clients

Tag: #neverrewrite

3 Signs Your Resource Allocation Model Is Working Against You

In software designTags , , , Publish Date14 ViewsLeave a comment jeffpsherman

3 Signs Your Resource Allocation Model Is Working Against You

After 6 posts on SaaS Tenancy Models, I want to bring it back to some concrete examples.  When your SaaS has a Single Tenant model, clients expect to allocate all the resources they need, whenever they want.  When every client is entitled to the entire resource pool, no client gets a great customer experience.

Here are 3 signs your Resource Allocation Model is working against you:

  1. Large clients cause small client’s work to stall
  2. You have to rebalance the mix of clients in a cell for stability
  3. Run your job at night for best performance

Large clients cause small client’s work to stall

This is a classic “noisy neighbor” problem.  Each client tries to claim all the shared resources needed to do their work.  This isn’t much of a problem when none of the clients need a significant percentage of the pool.  When a large client comes along, it drains the pool, and leaves your small clients flopping like fish out of water.

You have to rebalance the mix of clients in a cell for stability

When having multiple large clients in a cell affects stability, the short term solution is to migrate some clients to another cell.  Large clients can impact performance, but they should not be able to impact stability.  Moving clients around buys you time, but it also forces you to focus on smaller, less profitable clients.

Run your job at night for best performance

This is advice that often pops up on SaaS message boards.  Don’t try to run your job during the day, schedule it to run in the evening so it is ready for the morning.  When clients start posting workarounds to your problems, it’s a clear sign of frustration.  Your clients are noticing that performance varies by the time of day.  They are building mental models of your platform and deciding you have load and scale issues.  By being helpful to each other, your clients are advertising your problems.

Conclusion

These 3 issues have the same root cause; your SaaS’s operational data is mixed in with client data.  If you have any of these three problems, the time has come to separate your data from the clients’.

Fixing these problems won’t be easy or quick!  

The good news is that you can separate the data and change your resource allocation model in an iterative fashion.  Start by pushing your job service across the tenancy line.

Get value and regain control one incremental step at a time, and never do a rewrite!

A Guide to Prepare for a System Rewrite

In UncategorizedTags , , Publish Date33 ViewsLeave a comment jeffpsherman

I often talk about the Best Alternative To A Total Rewrite.  The idea that you should know the alternatives to a rewrite before making a decision.

Even when there is no alternative to a rewrite you still need to work through the common problems that cause the project to fail.

These open ended questions are designed to guide your preparations:

How will a rewrite solve your users’ pain?

Where is the current system failing your users?  How will a rewrite fix those problems? You and your fellow developers may hate the current codebase, but that isn’t a compelling argument.

Clients don’t want the Next Generation of your system.

Are there really no incremental improvements?

Now that you know what user pain you are trying to solve, is there really no way to resolve the problem in the current codebase?  

If the system is slow, is there really nothing you can do to make it faster?  Maybe a rewrite would make things so fast that users won’t notice any lag. But if a refactor would reduce frustrating lag by 50% in a month, you should refactor.

Once you've focused on your client's problems, reducing pain today is preferable to fixing the problem 6 months from now.

Do you have to recreate the existing system before adding new features?

After bugs and latency, the number one issue with old codebases is that it’s hard to add new features.  The original code was designed to expand in one way, and now it needs to expand differently. A rewrite will let you design a system to meet those new requirements.

What about a new system that is nothing but new features?  Can you find a way to make a new system that is a client of the old system?

A rewrite requires you have to recreate all the features of the existing system before adding the new features that create new business value.

How will you ensure that the new system doesn’t have the same problems as the original system?

The forces that caused the original system to go off the rails are going to work against the rewrite too.  

Management didn't want to spend time on unit tests?  They still won’t.  

Constantly changing business requirements?  Just wait until the demands aren’t constrained by the existing code.

Inadequate resources, logging, metrics and other tools?  A rewrite won’t make any of that better.

After a brief honeymoon a rewrite will face more pressure than the original system.  You need a plan to keep all of those external forces at bay.

What’s the release plan?

Replacement is not a release plan.  How is the rewrite getting into production?  Can you find a way to run the two systems in parallel?  Can you replace things a piece at a time?

You will have to release the new system eventually. "When it's done" takes forever.

Conclusion

When you propose a rewrite, you need to be able to answer these questions to your teammates and managers.  Bringing the questions and answers up in your initial pitch will show that you’ve thought things through.

Don’t proceed until you can answer all five questions!  You just might happen to discover an alternative to a total rewrite.  Even if you don’t use it, you can move more confidently once you can speak to the alternatives.

Three Ways To Refactor a Legacy System – A Cheesy Analogy

In UncategorizedTags , , Publish Date33 ViewsLeave a comment jeffpsherman

Software is immortal, but systems age. They reach maximum capacity and can't scale to support additional clients. They get twisted into knots as your business evolves in ways the system wasn't designed to support.

Without constant vigilance you end up with a system that your developers hate to work on and your clients find frustrating. You realize the current system is holding your business back and ask for options.

The most common answer, unfortunately, is the "6 month rewrite", also known as "a big bang." Just give your developers 6 months and they will produce a new system that does all of the good things from the old system, and none of the bad.

The "6 month rewrite" almost never works and often leaves your company in a worse situation because of all the wasted time and resources. I'm going to try and explain why with a very cheesy analogy, and suggest 2 much more effective strategies.

A very cheesy analogy

Imagine, that this piece of string cheese is your system:

"A 6 month rewrite" or "big bang" is the idea that your developers are going to shove the whole thing in their mouths and chew the whole log.

You won't really see any progress during the system mastication, but you'll be able to see the developer's jaws chewing furiously.

6 months is a long time to have developers working on one and only one thing. Especially when the chewing takes longer than expected and you reach the 9, 12, 18 month point. If you stop you'll be left with this:

Your original system. Worse for the wear and tear, but fundamentally, the original system that is restricting your business.

It's the worst of all worlds, you get no value unless the whole cheese is chewed, and you loose all the potential value if you stop!

Cut it up INTO small pieces

A great strategy when your system is failing due to scaling issues is to cut it up and refactor small pieces. Scaling issues include your system not being fast enough, unable to handle enough clients, or unable to handle large clients.

You can analyze which of these pieces are responsible for the bottlenecks in your system and tackle just those pieces:

And if you have to stop work on a single piece?

Your potential loses are much smaller.

Steel threads

When your system has been tied in knots due to changing requirements, replacing individual pieces won't help. Instead, try peeling off small end-to-end slices, creating stand alone pieces that work the way your business works now:

This is the "steel thread" or "tracer bullet" model for refactoring a system.

It allows you to try small, quick, ways to build a new system. Each thread adds immediate value as it is completed. You don't run the risk of having a large body of work that isn't helping your clients.

Like the "small pieces" strategy, you can stop and start without much loss.

Conclusion

6 month rewrites are risky and likely to fail and leave you with nothing of value from your investment of time and resources. Small piece and steel thread strategies offer ways to quickly get incremental value into your client's hands, and greatly reduce the risk of wasted work. They're your best alternative to a total rewrite!

Talking bout my generation

In dev teamsTags , Publish Date22 ViewsLeave a comment jeffpsherman

In the world of SaaS software, nothing is as sure a sign that a project will fail than calling it The Next Generation.  No one wants the next generation of your software! Your clients don’t want The Next Generation, they want the service that they’re paying for.  If they wanted something revolutionarily different, they wouldn’t be your clients. Your internal users don’t want The Next Generation, they want tools that help them do their job.

The Next Generation is something created by developers to sugar coat a full rewrite of the existing software.  The Next Generation has no business value. If you need The Next Generation of your software in order to write a new reporting module, it’s a sign you’ve given up on the current system.

When developers pitch The Next Generation they are being lazy.  It in an admission that the developers do not understand the business or care about client needs.  The Next Generation has no release plan other than replacement, and any theoretical client value comes at the end of the project.  At the same time it consumes resources that could have been used to for incremental features or code improvements.

The Next Generation starts with great fanfare, then goes silent for 6 months.  Then the team starts growing! Not because of success, but the sunk cost fallacy.  The company has spent so much and things are so close. Good money after bad, critical months after lost months.  Around 12 months management starts to micromanage. At 18 months the project is declared a failure. The team lead leaves.  Often the managers are not far behind. After millions of dollars spent on The Next Generation, you’re still where you started.

In SaaS, clients are buying This Generation.  If your developers are done with This Generation, you don’t need The Next Generation, you need to find your Best Alternative to a Total Rewrite!

Replacement is not a release plan

In UncategorizedTags , , Publish Date18 ViewsLeave a comment jeffpsherman

Replacement is not a release plan, it’s a sign that you are solving developer’s pain instead of client pain.

Deployment gets glossed over in the pitch: First we will mimic the existing functionality.  Then turn off the old system.

Since the plan is to re-implement the current functionality, your developers can start immediately!  No need to talk to the clients since they won’t notice any difference until we show them all the wonder improvements!

Developers get super excited about these kinds of rewrites because it is all about them and their pain.  The plan fails because the client cares about client pain, not developer pain.

Don’t assume the client wants what are you giving them!  Don’t assume they would love for you to give them more features, better code, or anything that excites your developers.  A more common situation is that someone has full time job doing manual data extractions, transformations, and other manipulations that software could do in seconds and your developers could write in a week.

Find your client’s pain.  Appeal to your developer’s sense of empathy.  If they hate dealing with the system, have them imagine the low level person being kept in a pointless job.  It’s a good bet that once your developers find out how their software is being used they’ll find that there’s no need for a rewrite; the clients need new tools, not replacements.

Site Footer