Paradigm shifts

When I was last doing a design refresh of this website, I decided to try out Tailwind CSS as I’d heard a lot of folks talking about it. Their website describes the framework like so:

“Tailwind provides low-level utility classes that let you build completely custom designs without ever leaving your HTML.”

Don’t worry, I’m not turning this into a front-end dev newsletter, but indulge me for a minute and take a look at the HTML code block example that they lead with on their homepage:

<div class="md:flex">
  <div class="md:flex-shrink-0">
    <img
      class="rounded-lg md:w-56"
      src="https://images.unsplash.com/photo-1556740738-b6a63e27c4df?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=448&q=80"
      alt="Woman paying for a purchase"
    />
  </div>
  <div class="mt-4 md:mt-0 md:ml-6">
    <div class="uppercase tracking-wide text-sm text-indigo-600 font-bold">
      Marketing
    </div>
    <a
      href="#"
      class="block mt-1 text-lg leading-tight font-semibold text-gray-900 hover:underline"
    >
      Finding customers for your new business
    </a>
    <p class="mt-2 text-gray-600">
      Getting a new business off the ground is a lot of hard work. Here are five
      ideas you can use to find your first customers.
    </p>
  </div>
</div>

Do your eyes hurt yet?

WTF are all those different classes on every single element? This is effectively inline styling and that’s well known to be an anti-pattern, right? How do you re-use styles? How can this possibly be maintainable in a large app?

But here’s the kicker… I absolutely loved it!

And I’m not the only one. The initial shock to my inner software craftsman was soon forgotten as I was able to quickly knock up a decent looking responsive layout for my new site. I no longer needed to think over how to semantically name an element or consider in what future contexts I might want to re-use it.

But what has this got to do with serverless?

In software development, there are many tools, frameworks, services and engineering practices that you just won’t appreciate the benefit of until you actually try them out. Looking in from the outside, some of these will actively go against everything you’ve learned or done in your engineering career to date.

Developing serverless applications has several such paradigm shifts that can appear jarring to outsiders. A few examples:

• Relinquishing the portability of being able to easily switch cloud providers
• Abandoning local development workflows in favour of cloud-based ones
• Giving up your old faithful RDBMS
• Squishing all your different entities into a single table in DynamoDB

On the face of it, these items would put off many architects and developers from choosing serverless for their next project. But until they take the leap and try it out, they’ll never realise the other benefits.

I’m certainly not advocating that you try out every new tech you see. But if something catches your eye as being potentially valuable to you or your team but then you notice a seemingly big blocker, don’t let that completely dissuade you. Probe further. Ask yourself why does this work for the folks using it? How are they addressing this issue I’m concerned about? Could I come around to their way of thinking?

Be wary of naysayers arguing from a position of theory rather than experience. By all means listen to your inner software craftsperson’s concerns based on your own prior experience, but don’t let these dominate your decision.

“The most dangerous phrase a manager can use is ‘We’ve always done it that way.’”
(Grace Murray Hopper)

Stay curious!