|
|
|
|
|
|
by dasil003
4445 days ago
|
|
|
It's about striking the right balance. I don't really agree with the original totem-pole idea that devs can do anything QAs and ops can do. While it may be true that a good dev is capable of muddling their way through any challenge because they know how to get around the numerous blocks thrown up by technology, there are definite skills to QA and Ops that developers may be lacking and which will lead to the dev being a poor substitute. That said, I think devs have skills which are applicable anywhere in an organization. This goes back to the virtue of a programmer being laziness. Being able to see how to build systems and automate things is something that is potentially useful everywhere. In the cases of ops and product support, there is an especially large amount of value from having devs poking their head in from time to time to pick off easy targets for improved automation, reporting, logging, or what-have-you. |
|
|
Yes. My company has tried for a good many years to keep product development partitioned from operations. We build stuff, through it over the wall, and let the ops team deal with it. Certainly, we give support where necessary, but it tends to be grudgingly given, and we never actually track time spend doing that support. I've been pushing, along with several other developers, that we at least need some sort of rotating product support team so we can work with ops to resolve problems in the field without disrupting our own timelines. We've moving in the right direction, but there's a lot of inertia to overcome.