June 4, 2018 at 9:08 pm
Comments posted to this topic are about the item The Journey to DevOps
June 5, 2018 at 4:42 am
As a DBA who has been both developer and systems eng, I completely agree.
August 9, 2018 at 7:19 pm
I'm a bit shocked to see such a shortage of replies - every developer, every DBA, and everyone who deals with customers' (or operations') problems should see this topic as illustrating some of the most important lessons they need to learn. As of course should every manager who thinks developers should never get near production or that customer support should be done on the cheap and not involve costly developer time. I have noticed that there are some companies that still have managers who work that way, and I wish all you non-responders a bit of good luck - may you never be stuck with sucj awful bosses.
It was in the early 1970s that I first decided that I wanted to get rid of walls bewteen development and QA and operations/customer support. That didn't initially do me much good, people mostly thought I was crazy, but my effectiveness as technologist and manager of several projects at once prevented it doing me much harm. I became quite nasty to developers who thought dealing with customers' problems were beneath their level, and further annoyed the QA people by refusing to hand systems over to them that I knew were too flawed to be releasable. The result was, of course, that we delivered software that was far more reliable than the team had ever delivered before. That wasn't devOps, it was far more primitive, but the base ideas and aims were the same as those of devOps, and even in half-baked form that worked a lot better than other approaches in the 1970s.
I think that I actually managed to deploy what's now called devOps in 2004 (I think). In 2002 - 2003 development at Neos was a mess - aimlessly wandering. Then, after a financial crisis and some shedding of staff, I had management of development added to my responsabilities, and made it co-operate sensibly with customer support and with the creative team. Bingo - we had a structure that worked (and far fewer developers than before) - a very small structure (Neos was a very small firm) but it worked. Having a simple arrangement where people cooperated instead of being three departments who didn't want to work together allowed it to be much smaller than before without any decrease in output (actually we got some increase, I think).
Tom
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply