How to handle questions where the answers may depend on the platform (OS)?

Question

Consider the various answers to these questions I asked already:

• How to implement a frozen test environment?
• How to avoid continuous integration-caused instabilities in test environments?

Interestingly enough, part of the answers to each of these questions somehow indicate something like "If you're trying to do this on a platform (OS) like a mainframe, or an AS400, then the answer is so and so".

So far I intentionally tried to avoid adding any indications/restrictions in my questions with (eg) something like so:

I'm familiar with how this is done in (eg) a mainframe, but I wonder about the distributed world.

My questions:

• How to handle questions where the answers may depend on the platform (OS), should I try to already indicate the platform for which I'd like to be the answers about? Or should I rather leave that open, so that where needed in the answers an indication about the platform is included?
• What kind of tags might be relevant (such as mainframe-alternatives)?
• Imagine a question doesn't include such indication, with answers like "if I would be asked this question in a mainframe environment, then this is what my answer would be", is that to be encouraged, or rather discouraged?

Answer 1

Personally, if I am knowledgeable in multiple ways to solve a problem, I will attempt to articulate them all, depending on the depths I need to go into for each answer this might be to multiple questions.

Equally, if someone has responded to the question for Product X and I can answer it for Product Y then I will add answer for Product Y. Sometimes the OP comes back to you and says it was the other guy who solved the problem, occasionally they don't, and you have a one vote answer hanging around, might solve someone's problem one day, though.

Finally, an approach to answering questions which focus on the strategies used to solve the problem is a valuable education tool as a strategy is an enduring answer that can be applied across many problem domains and technical stacks - it is always worth providing concrete examples on how this can be technically achieved to support your strategy.

Answer 2

While DevOps implements Lean philosophy, what we aim to do is to deliver customer value (faster and better).

If you are an engineer, and decisions for the platform are already made (sometimes, not by yourself), you can't do much about taking a strategic decision.

This puts an assertion on things which have to work fast in current context.

Still, some time the daily business context might change, so it's important also to know the methodology and not just a quick fix. Also, for a quick fix it's important to understand the risks and know about alternatives.

DevOps is daily applied scientific method, and learning and communication for these purposes should be fun on both sides!

Therefore I'd say best is if you see such question:

• Generally, step back from the doing to the rationale. Highlight the "why" before the "how".

• Put the problem into context using professional platform-neutral terms and capitalize on DevOps approaches and methods relevant in this context. This puts you also in sync with the question poster and educates him/her what they are actually doing, sometimes they might be not aware (add well possible misenterpretation on our side and get messy communication in worst case)

• Then, if you know the solution in the platform context, provide also an insight why it follows from the approach/method. It is also good not to explain everything into last detail but maybe give hints for further research/troubleshooting.

• Talking about alternatives, assert the importance of talking to the customer/stakeholder in terms to understand the requirements and risk assessment.

• Demonstrate your practitioner experience and give examples from your experience in terms of your NDA allows, come on, all or most of us work with open source components, so there will be enough examples. Share relevant resources you've recently read.

Examples how I've tried my best along these lines in two recent answers (admittedly in two of these three cases the topic was to make a decision and in the third one there was a possible choice between products of same vendor):

• Explain that (also light-weight) due diligence and vendor selection might be risky if customer reduces this choice just to the lowest price factor or delegates responsibility for such decisions to the engineer.

• Give pragmatic reasoning on and disenchant a little bit the "magic" of deployment and configuration automation tools from computer science perspective.

• Put required cloud solution in common production context.