Reply to post: Way to be completely unbiased

Way to be completely unbiased

"Robin sits in the stand-up meeting, arms crossed, each morning mumbling "Well, I wrote some code" and then takes that long, loud sip of tea."

OK. You clearly went to some effort to always mention Robin in a nasty light. That's not going to help you convince those of us who think devops is pointless to like your argument. Maybe next time, you could grant that there are valid questions such that the most positive term for someone who didn't buy in immediately isn't "justifiably crotchety".

Here's the major problem with devops. We're not sure what it really is. We understand that you think it's a thing, but your articles seem to contain sections that were written by the "big buzzword generator". To me, a lot of them seem to say, under the jargon, that there are problems and we need to make them into not problems. It doesn't say how to do that, other than making some suggestions that we already know about. For example, having meetings and discussions seems to be a major part, with the various sections having contact with each other so that a problem noticed by one can be made known to the others so that one of them will make it into a not problem. That's not new. The reason a lot of software is crap isn't because people were thinking "I never thought that one group should note problems to the responsible group", but because the responsible group didn't care, the problem went to the bottom of a pile of papers, or management pushed the software through.

In addition, devops seems to be a project that, whatever else it does, will generate a lot of paperwork. I hate to inform you of this, but having systems requiring a lot of incidental work just to keep the system running makes things bog down. For example, the company I used to work for, where we all had to get up and have a meeting that often lasted at least four hours, during which everyone discussed their projects, was counterproductive. I had nothing to do with many of those projects, so while I listened to details that I couldn't use and problems I couldn't help to solve, I was not actually doing my job. That meeting system has, I'm told, been canceled.

Here's what you have to do to start to satisfy me with this devops system, if you're interested. First, stop using clearly biased language, perhaps to try to sound humorous. It's irritating me, at least. Second, be really clear about what each thing is that you're talking about. If a theory says do small unit tests, don't phrase it in several paragraphs of explaining what incidental systems are required, say "run many small unit tests". Finally, explain not just what the system is, but why it's going to work in practice in the real world. Explain how someone explains the philosophy to a manager who actually listens and wants to understand, and how to use it to avoid the problems that actually exist.