{"id":38,"date":"2020-02-12T21:15:19","date_gmt":"2020-02-12T21:15:19","guid":{"rendered":"http:\/\/naftalin.info\/maurice\/professional\/?p=38"},"modified":"2021-01-15T14:01:08","modified_gmt":"2021-01-15T14:01:08","slug":"dijkstra-and-devops","status":"publish","type":"post","link":"http:\/\/naftalin.info\/maurice\/professional\/2020\/02\/12\/dijkstra-and-devops\/","title":{"rendered":"Dijkstra and DevOps: Is Programming Doomed?"},"content":{"rendered":"\n
\"\"
Credit: The University of Texas at Austin<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n

I don\u2019t suppose that outside academic circles the name of Edsger Dijkstra is nowadays familiar to many people, but it should be: he was a giant of computing science who could claim, over the four decades of his research and teaching, extraordinary achievements that included the first Algol-60 compiler; the popularisation of structured programming (he coined the term); many important algorithms; and the concepts of mutual exclusion, semaphores, and deadlock, in work which practically invented the field of concurrent programming. In the 1970s and 80s, it seemed he had been everywhere, laying the foundations of almost every area of computing.<\/p>\n\n\n\n

Dijkstra was always guided by a fierce determination that\ncomputing problems should be both formulated and solved in simple and elegant\nways. His famous paper \u201cOn the Cruelty of Really Teaching Computing Science\u201d\nargued that computer programming should be understood as a branch\nof mathematics. On software engineering, he famously wrote that \u201cit has\naccepted as its charter \u2018How to program if you cannot.\u2019\u201d People generally take\nthis to be a condemnation of software engineering as a discipline, and he may\nhave meant it that way when he wrote it in 1988. But at an earlier time he had\nused that term for himself, so it seems more likely that he was disparaging the\npeople calling themselves software engineers. (For Dijkstra, disparaging people\nwas actually his normal way of relating to them.)<\/p>\n\n\n\n

What does this have to do with anything now? I\u2019ve been thinking about Dijkstra recently in the context of my late adoption (late adoption, my life\u2019s story) of DevOps and cloud technologies. Cloud technology has survived the hype cycle\u2019s Trough of Disillusionment to become fully mainstream, and AWS as currently the leading provider can be taken as representative. Does Dijkstra\u2019s view of the principles that should underlie software engineering have any relevance to people working with it?<\/p>\n\n\n\n

Two aspects of the AWS offering stand out immediately: the sheer\nnumber of its services, and the diversity of the abstraction level that they\nprovide to its user. For 2019, Wikipedia lists 165 AWS services, covering areas\nincluding computing, storage, networking, database, analytics, application\nservices, deployment, management, mobile, and IoT tools. Even developer tools\nare provided \u2013 AWS provides Cloud9, a web-based IDE for the most popular\nlanguages. The intention is clearly to provide every single tool or environment\nneeded to develop, deploy, and maintain any application, from toy to enterprise\nscale. Amazon may have the first-mover advantage in this, but Azure and Google\nCloud are in pursuit, with other heavyweights like IBM Watson and Oracle Cloud\nnot far behind.<\/p>\n\n\n\n

How do these services relate to software engineering as Dijkstra\nwould have liked to think of it? We can\u2019t know what he would have made of the\nproblem of mastering complexity of modern enterprise systems, which are\nenormously larger and more complex than anything in his day, but we can guess\nthat he would certainly have scornfully excluded from his definition of\nsoftware engineering the many services devoted to cost management, governance,\nand compliance that bedevil an old-fashioned software engineer aiming for AWS\ncertification. But most of the services that constitute a cloud offering are\nactually aimed at the classical problem that software engineering addresses:\nmanaging the complexity of large systems. They do this by providing a giddying\nvariety of ways to compose different operational and computational libraries.<\/p>\n\n\n\n

And, in fact, these libraries only continue the tradition of\never-increasing abstraction and power provided to the client programmer \u2014 or\nDevOps engineer, as they will now usually be. I started my working life close\nto the bare metal, at the end of the assembler epoch, then moved on to coding\nwell-known algorithms and data structures in a high-level language, then saw\nbest-of-breed implementations of those algorithms and data structures\nincorporated into libraries that I could use, then saw those libraries combined\nwith compilers and runtimes to form a platform on which a client program sits;\nnow many, many layers up from the hardware. So I can\u2019t say that increasing\nabstraction is anything new.<\/p>\n\n\n\n

What is new is the way that cloud services integrate operational concerns like provisioning, scaling, and failover into the same framework as traditional data manipulation. DevOps engineers can script the horizontal scaling policy for their application using the same development tools and in the same language that they use to implement their sorting algorithms. You could imagine that as the developer\u2019s job has ascended in abstraction, so it has also broadened to devour the jobs of the application architect, the data centre designer, the DBA, and in fact almost everyone who ever had any role in the management or use of computers. (Another way to look at this would be that Amazon and its rivals are using automation to deskill these jobs to the point that even developers can do them, or simply consume them as services. Amazon calls this \u201cdemocratizing advanced technologies\u201d.) However we feel about the casualties of this kind of progress, I think you can reasonably argue that it makes sense to integrate all these functions into a single discipline of, say, systems engineering. <\/p>\n\n\n\n

Where next, then? Is the role of programmer doomed? Are Dijkstra\u2019s\ninnovations destined to become essential but forgotten, embedded deep within\nblack-box systems that developers use without understanding \u2013 just like modern\nhardware, in fact? I\u2019m forced towards that conclusion, though I continue to\nargue that we should value an understanding of the inner workings of our\nblack-box systems: even when we can just about get by without it, having that\nunderstanding will improve our daily practice. And, of course, not everyone\nworks on applications headed for the cloud; smaller-scale systems, including\nfront ends of various kinds, will continue to be important. But more than\nanything, Dijkstra\u2019s real principles, his relentless focus on abstraction and\nsimplicity, remain as relevant as ever, to enterprise DevOps engineers as much\nas to embedded system programmers.<\/p>\n","protected":false},"excerpt":{"rendered":"

I don\u2019t suppose that outside academic circles the name of Edsger Dijkstra is nowadays familiar to many people, but it should be: he was a giant of computing science who could claim, over the four decades of his research and teaching, extraordinary achievements that included the first Algol-60 compiler; the popularisation of structured programming (he […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/38"}],"collection":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/comments?post=38"}],"version-history":[{"count":7,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/38\/revisions"}],"predecessor-version":[{"id":102,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/posts\/38\/revisions\/102"}],"wp:attachment":[{"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/media?parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/categories?post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/naftalin.info\/maurice\/professional\/wp-json\/wp\/v2\/tags?post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}