Moving and Working

We remember the era of “move fast and break things”, right? It felt edgy and cool, but I’ve never been cool and it didn’t feel right to me.

I like to focus instead on “keeping things moving” and “keeping things working”. The “move fast and break things” saying makes it sound a bit like moving and working are in contention — and to some degree they are — but I prefer to think of them as two pillars supporting the system, and it’s important to keep them in balance. If something isn’t working, it may not have the luxury of getting to move nicely. And something that isn’t moving likely won’t be working for much longer.

So what’s involved in keeping things moving? Try not to let yourself get stuck in place. And if you are stuck, you push and prod, seeing what’s keeping you stuck or rocking yourself out of that stuck position. I value any sort of movement, because even movement in the wrong direction can show you how to move in the right direction. So for me, this comes down to experimenting, researching, poking, jiggling.

I find this is much more effective when it takes the form of something actually happening in the real world (or the virtual world of data). Thought experiments and working things out on paper can be helpful, but nothing shows what will happen like the actual thing happening.

This can range from the simple and small to the larger and more-involved. Recently I’ve done things like muck about with Tailwind CSS classes to see how to make a page look the way I’d like, and add a database index to see how (or if) it’d affect the performance of a too-slow query. And less-recently, I worked on a Stripe integration using the customer portal to see what control I could have over subscription creation and changes — and that has its own connection with seeing the actual thing happening with their introduction of test clocks, which let you fast-forward through time instead of waiting around.

What about keeping things working? This can feel more involved, especially in the world of Continuous Deployment (CD) where any change we make is potentially mere moments from production. Outside of special circumstances, we don’t want to take systems down — not for planned downtime and especially not the unplanned kind. With this in mind, tools and techniques have been developed for handling movement while keeping things working. You probably know some of these: automated tests and Continuous Integration (CI), staging and canary environments, feature flags, and more.

Now here’s the best part: these tools and techniques for keeping things working also help with keeping things moving. They work on both pillars, raising the entire system at once instead of having it teeter back and forth. A staging environment will help you verify (or disprove) assumptions, maybe operating at a larger scale than a local development environment or simply making it easier to share your findings. Feature flags will encourage you to build up a feature in a controlled, integrated fashion instead of trying to complete it off to the side and hope it plugs in well. Automated tests give you a safety net, letting you move quickly and confidently and pointing out where you might have made mistakes or missed something.

And that’s the whole point. The system needs to move, to adapt. It needs to work, to be available. And it needs that balance, moving and working, adaptation with availability. Availability without adaptation is stagnation. Adaptation without availability is a breakdown, random mutation, chaos.

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.