<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>jstimpfle</author><text>Counter-wit: Why can&amp;#x27;t people get their software to work with the existing libs? Hint: It&amp;#x27;s very rarely that the existing libs disqualify.</text></item><item><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></item><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>bluejekyll</author><text>this is the core of the problem between Devs and sysadmins. Sysadmins come from a mindset of a polished working system which never needs to change. They deliver stability and reliability to the business.&lt;p&gt;Devs come from a mindset to actively create change. This is to add new features and deliver new value and product to the business. As a Dev I do have to say that many Devs don&amp;#x27;t have enough experience in operations to understand properly how to help sysadmins, many don&amp;#x27;t understand the complexities of that job.&lt;p&gt;These two perspectives are at odds, and they should be. The new tools, like docker, start giving everyone what they want... Devs pick their dependencies, and in theory, can&amp;#x27;t stomp on the sysadmins pristine environment.&lt;p&gt;To respond directly to your question: because there are new things available in new libraries that allow us to develop new features!</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>jstimpfle</author><text>Counter-wit: Why can&amp;#x27;t people get their software to work with the existing libs? Hint: It&amp;#x27;s very rarely that the existing libs disqualify.</text></item><item><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></item><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>adrianN</author><text>People could do great things just with punch cards, yet somehow technology kept marching on.&lt;p&gt;If developers want to use newer stuff usually they have a good reason. The ability to hack around the deficiencies of old dependencies does not mean that one couldn&amp;#x27;t get a better, cheaper solution with newer technology.</text></comment>