3 ms·

> well, it certainly does do that, but probably not in the way you were intending Well, you have to leave something to the Intelligence of the Reader :-) > an

• kragen 3y ago
  dijkstra wrote an extremely influential operating system, hoare wrote several influential compilers and worked with wirth on algol w, and they both made extensive progress on formal methods. neither of them would ever utter the phrase 'mere software'; the excellent body of theory they developed is about software and investigates software in detail. boehm's does not. instead he theorized about how to manage programmers, which is not at all the same thing, because your theories are not falsifiable. he does not rise to the level of being a theorist all of dijkstra, wirth, and hoare were instances of your 'Scientist/Engineer/Technician/Programmer/Coder' polymath. hoare still is
  • rramadass 3y ago
    The original discussion we were having was about Barry Boehm vs. Kent beck and not what you are moving to here. > boehm's does not. instead he theorized about how to manage programmers,... Absolutely not! "Software Engineering" is far far more than just "manage programmers". Either you are unaware of his work or are intentionally downplaying it. His wikipedia page lists his works/achievements for everybody to read/study. He was a first-class theorist in the fields of "Software Engineering Economics", "Software Process Methodologies" and "Software Engineering" to name a few. I am well aware of the works of Djikstra/Hoare/Wirth/etc. and how their work is different from that of Boehm's/Parnas'/etc. For the purposes of our discussion i am lumping them under the term "the greats" to highlight their fundamental and complimentary contributions to the field.
    • kragen 3y ago
      dijkstra on 'software engineering' https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF > Having described —admittedly in the broadest possible terms— the nature of computing's novelties, I shall now provide the evidence that these novelties are, indeed, radical. I shall do so by explaining a number of otherwise strange phenomena as frantic —but, as we now know, doomed— efforts at hiding or denying the frighteningly unfamiliar. > A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.". > The popularity of its name is enough to make it suspect. In what we denote as "primitive societies", the superstition that knowing someone's true name gives you magic power over him is not unusual. We are hardly less primitive: why do we persist here in answering the telephone with the most unhelpful "hello" instead of our name? > Nor are we above the equally primitive superstition that we can gain some control over some unknown, malicious demon by calling it by a safe, familiar, and innocent name, such as "engineering". But it is totally symbolic, as one of the US computer manufacturers proved a few years ago when it hired, one night, hundreds of new "software engineers" by the simple device of elevating all its programmers to that exalting rank. So much for that term. > The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. > Besides the notion of productivity, also that of quality control continues to be distorted by the reassuring illusion that what works with other devices works with programs as well. It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications. you're bringing up the very real achievements of people like dijkstra and parnas in order to confuse the reader into putting boehm in the same category, as if he had achieved something similar. perhaps he could have, he was a smart guy, but he didn't, probably because he believed in 'mere software'. he ended up as a snake oil merchant, a successful one who found a lot of buyers. you're in danger of wasting your life the same way