Software Engineering in WordPress, PHP, and Backend Development

Tag: Project Guardrails

Project Guardrails: Writing To Production

In the past few articles, I’ve talked about a couple of things (saved for actually writing to production) that help to run a successful project:

  1. The dangers in “design by committee,”
  2. Considerations for provisioning an environment.

The last thing I want to address the learning I’ve experienced thus far is about maintaining the proverbial keys to the kingdom of writing to production and why that matters.

Continue reading

Project Guardrails: Provisioning Environments

This series of brief articles is made up of a few things I’ve learned over the last few years of running projects based in the area in which we (assuming you’re reading this coming from the same part of the industry I do 🙂) work.

If you’re just stumbling across this, the series is covering some factors that are important for a project:

  1. There should be no “design by committee.
  2. No one else other that the core development team should be able to provision development, staging, and production.
  3. No one should be able to write to production but the development team (and even then, there should be a deployment process).

I don’t really like making hard and fast rules like this namely because things change over time either by necessity or by more experience. This is why I like “guidelines.”

But at the time of this writing, these are the things I see playing out.

Continue reading

Project Guardrails: Design By Committee

When you’re contracted to build a solution for others – primarily on the web since that’s the area in which I work – I think that there are a number of factors that are important for a project:

  1. There should be no “design by committee.”
  2. No one else other that the core development team should be able to provision development, staging, and production.
  3. No one should be able to write to production but the development team (and even then, there should be a deployment process).

I’m always hesitant to make statements like this as they come off as dogmatic, but I find that the longer I work in this industry, the more I think these three rules are important.

Or perhaps they are really just guidelines. After all, there are shots called before we actually get stuff done.

Regardless of if they are more suggestions or rules doesn’t really matter. There are reasons that we all arrive at the conclusions that we do, right? And so over the next few posts (rather than one long post), I’ll share the reasons I’ve found these three rules to be important.

Continue reading

© 2024 Tom McFarlin

Theme by Anders NorenUp ↑