2 minute read

Context

Most Python used by platform engineers starts life as a small script:

  • a CI/CD helper
  • a deployment check
  • a config transformer
  • an API wrapper

Many of those scripts quietly grow into critical systems.

This post exists to help answer a recurring question:

When does a Python script need structure—and what kind?

The goal is not academic purity, but maintainable automation that doesn’t collapse under its own weight.

Core Python Concepts (Quick Refresher)

Instance Methods

Instance methods operate on a specific object instance and always receive a reference to it:

def instance_method(self):
    ...

This enables behavior that depends on object state, which becomes important as scripts gain responsibility.

Initialization with __init__

The __init__ method configures an object at creation time:

def __init__(self, config):
    self.config = config

For automation, this is often the cleanest way to:

  • inject configuration
  • pass credentials or clients
  • avoid globals

Design Patterns (Why They Exist)

A design pattern is not a rule — it’s a proven response to a recurring problem.

Patterns matter most when:

  • code has multiple responsibilities
  • behavior varies by environment
  • logic is reused across pipelines or tools

They matter least in:

  • one-off scripts
  • throwaway experiments
  • linear, single-purpose jobs

In Practice: Python as Automation Glue (Platform Engineers)

When patterns help

Examples:

  • CI/CD pipelines with multiple steps
  • Validation frameworks
  • API-driven workflows
  • Reusable internal tooling

Patterns like Factory, Strategy, or Builder help manage variation without conditionals exploding.

Example: choosing a deploy strategy based on environment.

strategy = DeploymentStrategyFactory.from_env(env)
strategy.deploy()

This beats:

if env == "prod":
    ...
elif env == "staging":
    ...

once the script grows beyond a dozen branches.

When patterns are overkill

Patterns hurt when:

  • the script is under ~100 lines
  • logic is linear
  • no reuse is expected

Over-structuring early is one of the fastest ways to make automation painful.

Rule of thumb:
If the script isn’t annoying yet, don’t “architect” it.

SOLID Principles (Applied Pragmatically)

SOLID exists to keep humans sane, not to satisfy theory.

Single Responsibility

One script or class should do one thing well.

In automation:

  • parsing config
  • validating inputs
  • executing actions

These are often separate concerns.

Open / Closed

Prefer extending behavior without rewriting existing code.

In pipelines, this often means:

  • adding a new handler
  • registering a new strategy
  • plugging in a new backend

Liskov Substitution

If you swap one implementation for another, nothing should break.

This matters when:

  • mocking APIs
  • switching cloud providers
  • changing execution environments

Interface Segregation

Avoid “god objects” that do everything.

In Python automation, this usually means:

  • smaller classes
  • narrower function contracts
  • fewer implicit side effects

Dependency Inversion

Depend on abstractions, not concrete implementations.

This is what makes:

  • testing possible
  • refactoring survivable
  • pipelines adaptable

In Practice: Python as a System (Software Engineers)

As automation code lives longer, it starts to look like an application:

  • state accumulates
  • edge cases grow
  • people depend on it

This is when:

  • SOLID pays off
  • patterns reduce risk
  • structure prevents regressions

The same principles apply — just more strictly.

When This Is Too Much

Be honest about context.

You probably don’t need:

  • factories
  • abstract base classes
  • deep inheritance

for:

  • one-off scripts
  • glue code with no branching
  • experiments

Engineering judgment is knowing when not to apply a principle.

Takeaways

  • Platform engineers use Python as glue — and that glue often hardens
  • Design patterns are tools, not obligations
  • SOLID helps when scripts become systems
  • Over-architecture is as harmful as under-structure
  • The right amount of design is contextual

If a Python script feels fragile or scary to touch, it’s usually time for some structure — not necessarily all of it.

You May Also Enjoy