<story><title>Software Developers Should Have Sysadmin Experience</title><url>http://blog.professorbeekums.com/2017/01/software-developers-should-have.html</url></story><parent_chain><item><author>bandrami</author><text>As a grumpy evil sysadmin, I think the good Professor misses where the real disconnect is, at least nowadays: stack management.&lt;p&gt;Why do things like Docker exist? Because developers got tired of sysadmins saying &amp;quot;sorry, you can&amp;#x27;t upgrade Ruby in the middle of this project&amp;quot;. Why does virtualenv exist? A similar reason.&lt;p&gt;Containerized ecosystems (which is to say basically all of them now) are really a sign of those of us on the sysadmin side of the aisle capitulating and saying that developers can&amp;#x27;t be stopped from having the newest version of things, and I think that&amp;#x27;s a bad idea.&lt;p&gt;15 years ago, when a project would kick-off, as a sysadmin I&amp;#x27;d be invited in and the developers and I would hash out what versions of each language and library involved the project would use. This worked well with Perl; once the stacks started gravitating to Ruby and Python it was a dismal failure.&lt;p&gt;Why? Because those two ecosystems release like hummingbirds off of their ritalin. Take the release history for pip[1] (and I&amp;#x27;m not calling pip out as particularly bad; I&amp;#x27;m calling pip out as particularly average, which is the problem): in the year 2015, pip went from version 1.5.6 to 8.1.1 (!) through 24 version bumps, introducing thirteen (documented) backwards incompatibilities. Furthermore, there were more regression fixes from previous bumps than feature additions. You&amp;#x27;ll also notice that none of these releases are tagged &amp;quot;-rc1&amp;quot;, etc., though the fact that regressions were fixed in a new bump the next day means they &lt;i&gt;were&lt;/i&gt; release candidates rather than releases. Ruby is just as bad; the famous (and I&amp;#x27;ve experienced this) example is that an in-depth tutorial can be obsoleted in the two weeks it takes you to work through it.&lt;p&gt;Devs are chasing a moving target, and devs who haven&amp;#x27;t been sysadmins may have trouble seeing why that&amp;#x27;s a bad idea.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pip.pypa.io&amp;#x2F;en&amp;#x2F;stable&amp;#x2F;news&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pip.pypa.io&amp;#x2F;en&amp;#x2F;stable&amp;#x2F;news&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>AlexB138</author><text>As a Sys Admin turned Automation&amp;#x2F;Tools Engineer, I think you&amp;#x27;re missing part of the point. You&amp;#x27;ve got the beginning of it right in saying that Sys Admins used to be involved in pinning down versions, and even in why that was necessary, but I believe you&amp;#x27;re incorrect in saying that the containerization technologies are bad for removing that.&lt;p&gt;Those technologies don&amp;#x27;t exist so Developers can get around Sys Admins and ignore your helpful advice. They exist to solve that problem that makes the Sys Admins role there necessary. It removes the underlying need for a Sys Admin to worry about the versions. Admins should see this as a good thing, but in my experience many dislike it because it takes them out of their Gatekeeper role. We shouldn&amp;#x27;t WANT to stop the Developers from from having the newest version of things. They aren&amp;#x27;t kids playing with toys that we need to nanny over, they&amp;#x27;re doing work that creates values and the fewer things we do to get in the way of that, the better.&lt;p&gt;If something breaks due to version changes, their testing should catch it. If things are breaking in production, we ought to get involved because there&amp;#x27;s some other problem, but before that we, as a profession, need to learn to get out of the way and let people work by letting technology handle the problems. The &amp;quot;Gatekeeper&amp;quot; mentality needs to die as quickly as it possibly can.</text></comment>
<story><title>Software Developers Should Have Sysadmin Experience</title><url>http://blog.professorbeekums.com/2017/01/software-developers-should-have.html</url></story><parent_chain><item><author>bandrami</author><text>As a grumpy evil sysadmin, I think the good Professor misses where the real disconnect is, at least nowadays: stack management.&lt;p&gt;Why do things like Docker exist? Because developers got tired of sysadmins saying &amp;quot;sorry, you can&amp;#x27;t upgrade Ruby in the middle of this project&amp;quot;. Why does virtualenv exist? A similar reason.&lt;p&gt;Containerized ecosystems (which is to say basically all of them now) are really a sign of those of us on the sysadmin side of the aisle capitulating and saying that developers can&amp;#x27;t be stopped from having the newest version of things, and I think that&amp;#x27;s a bad idea.&lt;p&gt;15 years ago, when a project would kick-off, as a sysadmin I&amp;#x27;d be invited in and the developers and I would hash out what versions of each language and library involved the project would use. This worked well with Perl; once the stacks started gravitating to Ruby and Python it was a dismal failure.&lt;p&gt;Why? Because those two ecosystems release like hummingbirds off of their ritalin. Take the release history for pip[1] (and I&amp;#x27;m not calling pip out as particularly bad; I&amp;#x27;m calling pip out as particularly average, which is the problem): in the year 2015, pip went from version 1.5.6 to 8.1.1 (!) through 24 version bumps, introducing thirteen (documented) backwards incompatibilities. Furthermore, there were more regression fixes from previous bumps than feature additions. You&amp;#x27;ll also notice that none of these releases are tagged &amp;quot;-rc1&amp;quot;, etc., though the fact that regressions were fixed in a new bump the next day means they &lt;i&gt;were&lt;/i&gt; release candidates rather than releases. Ruby is just as bad; the famous (and I&amp;#x27;ve experienced this) example is that an in-depth tutorial can be obsoleted in the two weeks it takes you to work through it.&lt;p&gt;Devs are chasing a moving target, and devs who haven&amp;#x27;t been sysadmins may have trouble seeing why that&amp;#x27;s a bad idea.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pip.pypa.io&amp;#x2F;en&amp;#x2F;stable&amp;#x2F;news&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pip.pypa.io&amp;#x2F;en&amp;#x2F;stable&amp;#x2F;news&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>awinder</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;gt; 15 years ago, when a project would kick-off, as a sysadmin 
  &amp;gt; I&amp;#x27;d be invited in and the developers and I would hash out
  &amp;gt; what versions of each language and library involved the
  &amp;gt; project would use
&lt;/code&gt;&lt;/pre&gt;
To wit: the new ideologies in infrastructure management are actually designed to solve the underlying problem that necessitated that kind of working setup.  Why should the version of a lib in one part of the software somehow pose existential threat to the infrastructure?  Engrain the dependencies into contained, independently deployable pieces, and make it so that app-level code can evolve without bringing down the world with it.  Make it easy to revert back, and&amp;#x2F;or utilize phased rollouts, and you&amp;#x27;ve got the ability to iterate quickly, keep pace with external dependencies, and it no longer has to be some scary thing that requires big back-and-forth meetings over mundane details.&lt;p&gt;(As for software that releases often, maybe it&amp;#x27;s an over-correction, but there&amp;#x27;s a reason things don&amp;#x27;t work as they did in the glory days, and that&amp;#x27;s because they were never really that glorious.)&lt;p&gt;This doesn&amp;#x27;t necessarily rule out the expertise of systems administration, because the platforms for all of this need to be built &amp;amp; maintained, and there&amp;#x27;s still a lot of work to be done on network boarder security, etc.  It&amp;#x27;s a movement that focuses systems administration to systems administration, instead of having to be this big org arbiter of microdecisions, and all the baggage that goes along with trying to be the gatekeeper of all.</text></comment>