Principle of Production Purpose Submissions

Steven Oxley recently authored an article regarding the concept of production purpose. In broad terms he was referring to careful scope planning for software projects as it relates to how that effort will impact production and derived value. I submitted responses to the questions.

Question 1: What is a principle that you've (re-)discovered during your work?

Q (Steven): What is a principle that you've (re-)discovered during your work? Bonus points if it's related to DevOps or Platform Engineering.

A (Charles): I agree 100% with production purpose. I deal with a lot of full stack deliveries. Customers are often not very interested in back end. It must just work 100% of the time, scale, be secure, cost effective, etc and that's it. I suppose the production purpose incorporates those objectives. On the front end yes, you get a lot of customer feedback on visuals and functionality. I've continuously re-discovered that tools make great developers better (like Terraform you mention). It has always been the tools as long as you have a developer that is good at problem solving. There are many great developers that can figure out any given problem with enough time, but tools will accelerate this process. There are so many tools emerging right now that the time to continuously evaluate and incorporate can be a challenge. Terraform is hot now, but will agents be able to write and maintain the terraform configurations for us soon?

Question 2: How have you noticed the principle of production purpose crop up in your work?

Q (Steven): How have you noticed the principle of production purpose crop up in your work?

A (Charles): The teams I work with often have to incorporate direct customer feedback. This goes straight to production purpose; you are being told what is needed for production. However, original projects always have situations where our teams will figure out an issue during iteration cycles that may be a future issue, so we build in advance of the customer feedback. We do this in cases where the issue is going to be an open and closed issue. These types of situations are mitigated by advance customer approval of features and designs, but they still crop up on complex projects.

Question 3: What are problems you've had with your production systems?

Q (Steven): What are problems you've had with your production systems that you've struggled to get other people to care about? If you have some, maybe you could try using the principle of production purpose to overcome some of the friction you're experiencing. If you do, please let me know how it goes.

A (Charles): When architecting solutions I always try to consider production throughput vs cost. It's easier to build for speed ignoring cost. Long term cost for many companies is often not a concern when building a new product as time to market is usually the priority. In the back of my mind I know that if I don't build for cost effectiveness and the company experiences hardship, it may mean turbulence. Wouldn't it be better if possible to seriously incorporate cost into architecture planning and mitigating any potential bumps? That's such an arbitrary thought process, and not directly related to developer responsibilities and rewards that it is ignored on many project teams. It is only after a cost saving initiative is launched that this kind of thinking can be rewarded usually.