Level 3 of the Stairway to Synapse Analytics: A nalyze Data Using a Spark Pool (2024-09-18)

When Do We Worry About Scalability?

"We need to get the code written for feature X. Can you finish this query today?"

We've all heard some variation of that request. We have a request or demand, and we need to get it done. We need to get code out so our business can advance, sell more things, get more customers, etc. There's always some reason to get new code pushed to production quickly.

However, many technical people want to ensure their code works well. At least, I believe most do. While most people can write code that works and meets the requirement, some don't know how to write code that performs well or don't know how to test their code to check. Often there isn't a large workload in dev or test environments to verify things.

There may not be a large workload in production either, at least not at first.

So, what do you worry about first: your code being used or performing well? That's a similar question to this one: Worry about Scalability or Popularity First? While most of us don't work for a startup and our organizations have some sort of financial stability, does popularity matter?

I'd say that for any feature you build, whether a startup mobile app or a legacy ERP system, you're still looking at this type of question. You want to know if it's used, and how often. That might determine if you spend more time on this feature or area. Maybe you have some idea of popularity, or just plan old use of the feature. In that case, certainly make sure it will scale to not only meet your data size now, but plan for some level of growth across the next 6-12 months.

If it's a new area of functionality for your application, then maybe you have no idea. In that case, the DevOps approach is get something working, a minimally viable version of your code or query, and then tune it later if it becomes a problem. Many technical people approach the endless number of tickets and requests they get like this.

The problem is management often doesn't budget in time to clean up the technical debt (to care about scalability).

My view for database code is that we should always be leveling up our database code knowledge. If we deploy bad code in production, and can't fix it, then at least we can avoid adding to the problem by writing the same poorly performing code again. Learn a better way to write that type of query. Whether you're splitting strings, finding islands and gaps, calculating running totals, or anything else. Learn what works well and write that code next time.

That helps your team balance the scalability and popularity-chase by producing good code the first time. Or at least, the next time.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums