2 ms·

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

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
- rramadass 3y ago
  I am afraid calling Barry Boehm a "Snake oil merchant" and that he didn't achieve much merely betrays your ignorance. You need to really study up on the history of the Software Engineering field and how it came to be what it is today before giving advice to others who may know more than you. Again, go through Boehm's wikipedia page and follow links from there. Here is his "Awards" section - https://en.wikipedia.org/wiki/Barry_Boehm#Awards https://en.wikipedia.org/wiki/Barry_Boehm#Awards I am fully aware of Djikstra's criticism and i am not sure what you hope to show by pasting a wall of text. Just to clarify, his criticism was appropriate at that time since the field was just coming into existence and there wasn't much nailed down. The situation now is very different, we have decades of research/models/experience for a sound basis mainly due to folks like Parnas/Boehm. It is actually funny for me to see you quote Djikstra since the whole XP/Agile rigmarole is the very antithesis of everything he stood for i.e. writing programs which are "correct" by design using Predicate Logic and not the XP/Agile method of "design and refactor a self-created mess as you go".
  - kragen 3y ago
    when i said 'snake oil' i was quoting dijkstra, who continued to hold that opinion of 'software engineering' (yes, including xp, perhaps especially including xp) until he died in 02002. so the logical implication of what you're saying is that dijkstra was ignorant—compared to you, apparently? if you think six paragraphs is a 'wall of text' you'd better stay away from libraries; if you ever saw a book you might die of shock parnas did actual software work. don't insult him by lumping him with boehm
    - rramadass 3y ago
      You might want to rethink how you communicate with people regarding subjects you have no clue about. A little humility goes a long way. The original discussion started with XP/Agile and Kent Beck where you quite clearly had nothing to defend their achievements against Barry Boehm's whose works you seem to know nothing about. So instead you drag in Djikstra's works which are not under discussion here and somehow think that is valid? Also twisting my words to read non-existent meanings into them is merely a feeble attempt at trying to mask one's ignorance.

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

rramadass 3y ago
I am afraid calling Barry Boehm a "Snake oil merchant" and that he didn't achieve much merely betrays your ignorance. You need to really study up on the history of the Software Engineering field and how it came to be what it is today before giving advice to others who may know more than you. Again, go through Boehm's wikipedia page and follow links from there. Here is his "Awards" section - https://en.wikipedia.org/wiki/Barry_Boehm#Awards https://en.wikipedia.org/wiki/Barry_Boehm#Awards I am fully aware of Djikstra's criticism and i am not sure what you hope to show by pasting a wall of text. Just to clarify, his criticism was appropriate at that time since the field was just coming into existence and there wasn't much nailed down. The situation now is very different, we have decades of research/models/experience for a sound basis mainly due to folks like Parnas/Boehm. It is actually funny for me to see you quote Djikstra since the whole XP/Agile rigmarole is the very antithesis of everything he stood for i.e. writing programs which are "correct" by design using Predicate Logic and not the XP/Agile method of "design and refactor a self-created mess as you go".
- kragen 3y ago
  when i said 'snake oil' i was quoting dijkstra, who continued to hold that opinion of 'software engineering' (yes, including xp, perhaps especially including xp) until he died in 02002. so the logical implication of what you're saying is that dijkstra was ignorant—compared to you, apparently? if you think six paragraphs is a 'wall of text' you'd better stay away from libraries; if you ever saw a book you might die of shock parnas did actual software work. don't insult him by lumping him with boehm
  - rramadass 3y ago
    You might want to rethink how you communicate with people regarding subjects you have no clue about. A little humility goes a long way. The original discussion started with XP/Agile and Kent Beck where you quite clearly had nothing to defend their achievements against Barry Boehm's whose works you seem to know nothing about. So instead you drag in Djikstra's works which are not under discussion here and somehow think that is valid? Also twisting my words to read non-existent meanings into them is merely a feeble attempt at trying to mask one's ignorance.