“I suppose that’s all very well if you don’t know how to design software.”
ouch. it's good to be reminded there are ways to do things beyond the ways we know, i suppose
(this was wirth's thought on incremental xp-style design, i guess)
ouch. it's good to be reminded there are ways to do things beyond the ways we know, i suppose
(this was wirth's thought on incremental xp-style design, i guess)
First, most software methodologies are for teams. Wirth himself was more concerned with the individual programmer.
Second, most software methodologies are for getting at least a constant performance out of teams. Improving the performance is a concern, too, but most and for all a constant performance will enable managers to be able to plan. That's also nothing Wirth would thought about.
Wirth would have wanted to get the most out of the individual programmer. Be the best programmer you can be to discover the best design that is inherent to a problem.
I can also see how that might be at odds with the idea of incremental design.
incremental design by refactoring is, quite precisely, intended to cope with the situation of not knowing how to design a system at the outset. however, inevitably at the outset you don't understand the problem well enough to discover the best design for solving it. there may exist some problems you understand well enough at the outset to come up with a workable design; there certainly exist others you do not, however wise and talented you are. the workable design consists entirely of things you know will work, and it does something you know is sufficient to solve the problem. sometimes you should do this
but it will never give you the best design, and sometimes it doesn't work at all. your initial design will probably do some things that, while sufficient to solve the problem, aren't necessary. the optimal design would avoid spending effort on those things. because you don't know all the things that will work yet, it's likely that the optimal design would incorporate things that you don't know will work at the outset. finally, there are problems you don't understand well enough to even come up with a workable design for, at the outset, but which you can learn enough to solve in the process of solving them
and that's what refactoring and incremental design is about: enabling your design to benefit from the things you learn in the process of building your system, so it actually can be the best design for solving the problem
But "Incremental Design"/"Refactoring" as practiced by XP/Agile/Scrum crowd is not that at all. It is giving up on "Upfront Design" altogether because Requirements/Design is subject to change anyway. The fact that you will have unknowns should not be an excuse to not come up with a blueprint i.e. Design for the overall system. The focus should be on the long-term with decisions/allowances/techniques made for extension/maintainability/refactoring within the blueprint. That is the point of "Upfront Design". The XP/Agile/Scrum crowd have effectively thrown the "baby out with the bathwater" with the result that their methodology has degenerated to "think short-term and make shit up as you go long-term".
See also Bertrand Meyer, "Agile! The Good, The Hype and The Ugly" - https://www.youtube.com/watch?v=ffkIQrq-m34
boehm suggests iterating through the different stages every 2–3 months. xp suggests iterating through the different stages every 2–3 minutes. scrum doesn't have any development practices at all, just management practices
when i look at the software barry boehm has written and the software kent beck has written i think it's clear that kent beck is far more accomplished. i don't know how good or bad boehm's designs were because i haven't been able to find any. reading his papers it seems to me that probably this is not because of his own ineptitude but because he was embedded in a company whose organization and incentives made it impossible to deliver quality software. this crippled his professional development as a programmer. trw in the 01980s made its living from defense contracts where they can billed customer hourly for their employees' time, so as long as their ass was covered with enough documentation, the more man-hours they spent on a project, the more money they made. consequently, as far as i can tell, they never wrote any software worth using, because for them software was just a cost of doing business, and neither has barry boehm after he left
reorganizing your own company to mimic trw in the 01980s is likely to sink you unless you, too, make your living from cost-plus contracts
not to say that there's nothing to be learned from boehm's work, but you'll have to pick carefully
by the way, possibly you are not a native speaker of english, but 'upfront design', 'requirements', and 'design' are not proper nouns, so should not be capitalized as perhaps they would be in german
But that is the problem, when everything is malleable, you have no fixed "Underlying Structure" which is what Design is all about. Iteration should always happen within a framework of understanding and not a free-for-all. This is why you have prototyping, plan one to throw away etc.
> most of the core practices of xp are focused on extensibility and maintainability.
I don't think this is specific to XP/Agile.
> i'm undecided on whether it's more difficult to do well than the big-design-up-front practice, and i think the answer is probably 'it depends'
True, this depends on what stage the product/project is at in its lifecycle.
> boehm suggests iterating through the different stages every 2–3 months.
It is a suggestion which can be lengthened/shortened according to project needs.
> xp suggests iterating through the different stages every 2–3 minutes.
Totally unworkable not to mention silly! I still have "Extreme Programming Explained: Embrace Change by Kent Beck" lying around somewhere so have to look it up on whether it is mins/days/weeks and at what stage of a project.
> when i look at the software barry boehm has written and the software kent beck has written i think it's clear that kent beck is far more accomplished. i don't know how good or bad boehm's designs were ... <rest of the para>
Violently Disagree! Barry Boehm's credentials - https://en.wikipedia.org/wiki/Barry_Boehm Writing mere software is no measure of how much you have thought/researched about important meta-issues surrounding the same i.e. "Software Development as Engineering Discipline". Kent Beck (https://en.wikipedia.org/wiki/Kent_Beck) offers nothing much here (consultant) while Barry Boehm (researcher/programmer/scientist/professor) is a giant in this field. The depth and importance of the latter's work far outstrips the former's. Also note the differences between Scientist/Engineer/Technician/Programmer/Coder roles.
> reorganizing your own company to mimic trw in the 01980s is likely to sink you unless you, too, make your living from cost-plus contracts
Not what i am talking about nor implying.
> not to say that there's nothing to be learned from boehm's work, but you'll have to pick carefully
There is much to be learned from Boehm's work if only to not reinvent the wheel.
> by the way, possibly you are not a native speaker of english, but 'upfront design', 'requirements', and 'design' are not proper nouns, so should not be capitalized as perhaps they would be in german
I use capitalization/scare quotes often to signal importance/nuance to the reader.
well, it certainly does do that, but probably not in the way you were intending
UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS
'course, i'm one to talk...
anyway, i think that if you want advice on programming, you should get it from people who are good at it. people who think software is 'mere software' are never going to achieve anything in the field and can be safely disregarded, however many awards and other credentials they receive. wirth's achievements as a Scientist/Engineer/Technician/Programmer/Coder were because he took software seriously, the opposite extreme from the 'mere software' viewpoint
Well, you have to leave something to the Intelligence of the Reader :-)
> anyway, i think that if you want advice on programming, you should get it from people who are good at it. people who think software is 'mere software' are never going to achieve anything in the field and can be safely disregarded, however many awards they receive.
Again, Violently Disagree! People who think Djikstra/Hoare/Boehm/other greats had not written much "code" to warrant being taken seriously and were "mere theorists" do not understand the first thing about Science/Research/Meta-whatever and Engineering/Implementation; the former is the bedrock on which the latter stands.
> wirth's achievements as a Scientist/Engineer/Technician/Programmer/Coder were because he took software seriously, the opposite extreme from the 'mere software' viewpoint
Not opposite, he was both a Scientist and an Engineer which is the source of his greatness. Languages/Compilers/OS/HDL/Processor design/Applications the man did it all.
all of dijkstra, wirth, and hoare were instances of your 'Scientist/Engineer/Technician/Programmer/Coder' polymath. hoare still is
> 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.
> 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
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".
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
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.
i read all these process guys back in the 90s: boehm, yourdon, mills, weinberg, beck. and, like boehm, i worked in dod-funded software projects on cost-plus contracts. i am dismissing boehm's work not just because dijkstra described it as snake oil but because decades of experience have shown most of it to be worthless
Merely to show the group of "the greats" in which i included Boehm. But we are not discussing his works here.
> i read all these process guys back in the 90s: boehm, yourdon, mills, weinberg, beck.
I too have read the works of these folks in the early 90s. Their work is all in different domains and not all of them "Process". Beck most certainly does not belong in this group. FYI, i was introduced to XP in 2000 at the company i worked for in Austin, Texas when they got Kent Beck himself to come in and teach us this new fangled concept called "Extreme Programming". I think i asked him about how he hoped to design and implement something like a OS with this "constant change" methodology; the answer was not satisfactory to say the least. Then of course the totally daft idea of forced "Pair Programming" which anybody who knew anything about Human Psychology/Organizational Behaviour would tell you is not workable unless the concerned people themselves seek it out. Nobody in the company practiced XP thereafter. If anybody is selling snake-oil it is the XP/Agile/Scrum proponents.
> i am dismissing boehm's work ... because decades of experience have shown most of it to be worthless
I am dismissing your dismissal of Boehm's work since through out this chain of comments you have not presented any evidence of any knowledge of Boehm's works. Do you know what is the COCOMO model and where it may/may not be applicable? Do you know what exactly is the Spiral Model and how to use it? I have pointed you to his distinguished career, awards earned and general standing in the industry and yet i have had no proof at all that you have read anything i pointed out. In short, you need to demonstrate competence with his work before anybody can take you at your word.
Finally, you also owe me an apology (though i have little hope that i would be getting one) for misrepresenting with malicious intent what i had said with your comments here https://news.ycombinator.com/item?id=38905726 and here https://news.ycombinator.com/item?id=38905477
> you deprecated achievements like oberon as 'mere software'
This is a straight-up intentional misrepresentation of what was said. It was in response to your claim of Kent Beck's achievements and nothing whatever to do with Wirth's.
If that is what you understood then you need remedial English comprehension classes.
Also my other comment here for reference - https://news.ycombinator.com/item?id=38907809