6

Consider the various answers to these questions I asked already:

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 -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?
2
3

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.

4
  • OK, makes sense, which is somehow similar to some of my answers. I.e. for cases where the question does not specify which (eg) patform or product it is about. In those cases, more and more I include in my answers some assumptions (eg: if I was to do this in a mainframe environment, then so and so). The risk with this kind of answer is that you get a comment from OPer like "your assumption is wrong", however that doesn't invalidate my answer anymore to the version of the question as it existed when I posted my answer. – Pierre.Vriens Mar 18 '17 at 16:53
  • If someone says my assumption is wrong that is fine it gives me an chance to revisit my assumptions, that can never be a bad thing. I have deleted many, many answers on SO because my answer has caused the author to change the question - I'm totally comfortable with that. – Richard Slater Mar 18 '17 at 21:13
  • yes but, there is a dowsite to it also ... sometimes I post answers on a site with custom code, taylored to a question, and then OPer may say "thank you, but I cannot use it because of another version or so ... (not mentioned in theO)". – Pierre.Vriens Mar 18 '17 at 21:27
  • @Pierre.Vriens That's the exact reason to close a question as unclear or too broad, to avoid getting answers unvalidated by a change to the question done after an answer which made the OP realize there's an important point missing. The best idea is to ask for precision in comments. – Tensibai Mar 21 '17 at 8:39
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .