A lexicography of dev and/or ops.
In the interests of facilitating communication at the speed of business and an improved time to market for geographically dispersed agile product development (or something), I’ve put together a personal reference guide for DevOps and similar methodologies. This small, ad hoc lexicon is intended to help me traverse the space between buzz and content. It’s posted for your benefit and/or consideration, with no guarantees or promises regarding increased efficiency. (Void where prohibited.)
What follows is a subset of that list (a minimum viable post, if you will) which I’ve transcribed directly from the Post-Its and bar napkins on which the bullet points were originally deployed.
DevOps: an ideology of fast delivery which focuses on communication between the programmers and the end-users. Code produced via DevOps may or may not fail early, but it’s statistically likely to fail often. But at least it’s not the Waterfall method.
OpsDev: an ideology of leading with the end user, with the full experience firmly defined. After all, there’s no sense in failing (early and/or often) if the Ops know what they want. Totally not the Waterfall design method, for reasons I’m not sure I can articulate.
OpsOps: the next stage of the software development evolution, whereupon the developers are cut out entirely and the Ops do their own code development. I mean, seriously — why put up with the middle-folk when you could just choose your own adventure? See also: ‘fog programming.’
DevDev: alternately, the “infinite waterfall” method. Development continues ad nauseum until either the company runs out of money or the lead programmer experiences a total existence failure. It’s turtle() methods all the way down.
DevNops: DevOps for ideas that no one actually wants to hear.
OpsNops: OpsDev for a user experience that doesn’t exist on this plane of reality. May require a change_religion() API call for the full experience. If used in the context of a Star Trek episode, this is the program that causes androids and/or supercomputers to malfunction. Use sparingly.
NopsDev: an absolutely fantastic idea that your team can’t put warm bodies on, ‘cos Reasons. But that’s okay, because we’re sure there’s a RESTful API and/or library for that already.
GroupDev: not a software development model per se, but representative of that moment in time when you realize you’ve had three separate teams working on independent solutions to the same problem. None of them will work, and they aren’t compatible. Which is fine, because none of them are what the Ops wanted anyway.
DoubleDev: It’s like DevOps, except that any time someone says ‘I don’t know’ during a Playback, they’re immediately covered in a viscous green goop the V.C.’s acquired at discount.
DoubleNops: Ops. (A negative times a negative equals a positive.)
There was also one Post-It with Dev(Ops(Dev(Ops(Dev(Dev))))) on it, but I’m still waiting on the return code to come back from tha~
~~~~~~~~~~
~~~~~
~~~~~~~~~~~~~~
~~~~~
~~~
NO CARRIER
