tag:blogger.com,1999:blog-5028009537158799436.post8638310910727016082..comments2023-07-10T04:50:03.236-07:00Comments on Building Real Software: Devops isn't killing developers – but it is killing development and developer productivityJim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5028009537158799436.post-34050987916202510922014-08-07T00:18:14.230-07:002014-08-07T00:18:14.230-07:00A few ideas:
Giving up developer productivity met...A few ideas:<br /><br />Giving up developer productivity metrics in favor of operational metrics is a good thing - after all, operational metrics can be directly related to business value, while developer productivity, regardless of how you measure it, less directly.<br /><br />Not all devs are on call all the time. IME it's usually one of the team members on call at any guven time, and the whole team does pager duty by rotation. This should give a developer plenty of time to focus and work on difficult programming tasks which require exquisite focus and the absence of interruptions.<br /><br />Even with interruptions, if you manage to train yourself in the disciplined way of development called TDD, dealing with interruptions becomes easy - the increments in which you work are tiny, and complex algorithms evolve, rather than being designed. (Of course, similar to agile development in general, nobody believes it before experiencing it first-hand.)<br /><br />What you loose in perceived productivity you more than make up (IMO/IME) in working on the things that matter and building them in a way that works better. Having a strong split between devs and ops often leads to neither delivering what the others need to efficiently cover business needs - which is probably the reason why IT departments were often not taken seriously and considered plainly stupid by other departments in the enterprise before devops.<br /><br />This being said, I think that productivity, measured as business value delivered by a devloper in a unit of time - this being the only relevant measure, actually - is likely to go up with devops, instead of down.<br />A_flj_https://www.blogger.com/profile/13123052099912825525noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-1450517507670270232014-07-30T10:27:16.001-07:002014-07-30T10:27:16.001-07:00A great article as usual.
But this time, I have t...A great article as usual.<br /><br />But this time, I have to disagree with you on many points.<br /><br />Rapid deployment to production doesn't leave time for manual testing or for manual testers<br />-> that is true if you implement continuous delivery as continuous delivery to production<br />to me, you can do continuous delivery to a test server and choose to deploy a given release to qa server that will go to production<br />the pipeline need to be automatic but manual testing is indeed possible in qa<br />the goal is to deploy to production as soon as possible<br /><br />This means everyone, especially your most talented developers, need to be available for ops most if not all of the time.<br />-> indeed if your application keeps crashing that is the case :)<br />but in my life, I deal with ops problem maybe once or twice in a week<br />I am far more interrupted by testers than by ops because they constantly want tiny improvements :)<br /><br />As more software is delivered earlier and more often to production, development turns into maintenance. Project management is replaced by incident management and task management. Planning horizons get much shorter – or planning is replaced by just-in-time queue prioritization and triage.<br />-> it seems to me that you are in a situation where you are constantly firefighting and having continous delivery increases the burden.<br /><br />The point I agree with you :<br />This way of working isn't better for developers, or worse necessarily. But it is fundamentally different from how many developers think and work today.<br /><br />that is true and to me this is mostly good because this is also true for ops : they now have less excuses to delay the delivery which has always been a burden to me and support teams ("hey dude, this bug was corrected 2 months ago and some clients still experienced it" <br />cblinnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-14754401810150206382014-07-29T15:33:16.099-07:002014-07-29T15:33:16.099-07:00Gripping read, I must admit!Gripping read, I must admit!Michaelhttp://michaelszymczak.comnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-38819768231394451142014-07-29T13:11:03.912-07:002014-07-29T13:11:03.912-07:00Julien, thank you for spotting the typo :-)Julien, thank you for spotting the typo :-)Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-81985480527673471252014-07-29T09:03:12.059-07:002014-07-29T09:03:12.059-07:00Title should be : "Devops isn't killing d...Title should be : "Devops isn't killing developers – but .." instead of "Develops isn't..."Anonymoushttps://www.blogger.com/profile/17455936292483242871noreply@blogger.com