31–40 of 64 posts
Earlier quoted context omitted.
Well my grandfather was born years after that event, so it is kinda surprising, especially considering his profession.
My still-alive father was born before Wirth, and my grandparents were born in the 1800s. Generations can span quite a range.
That being said, I was at a colleagues wedding and his grandparents were the same age as my parents, which was pretty odd.
Earlier quoted context omitted.
My still-alive father was born before Wirth, and my grandparents were born in the 1800s. Generations can span quite a range.
Yeah, mine too (although my father died a few years back). That being said, I was at a colleagues wedding and his grandparents were the same age as my parents, which was pretty odd.
People got married and had kids (age 15 for my grandma) early back in the day, not too odd.
Earlier quoted context omitted.
He's deriding the agile movement. He's saying if you don't know how to properly design software (up front), then he supposes that doing it in an iterative fashion is an acceptable alternative. The way he says it implies that he disapproves of it. In opinions such as this it pays to remind yourself that not everyone is faced with the same challenges. For all the esteem Wirth garners, I feel (at least at that time) his…
And that Worth worked primarily on systems that are many times smaller (maybe many orders of magnitude smaller) than today's biggest systems. It's no surprise, then, that the successful techniques are different. The right techniques to build a house, a skyscraper, a city, and a garden are different.
This is a dangerous and misleading metric. You're right that different scale needs different techniques, but comparing sizes of actually existing systems in this way it's very easy to conclude your strongest designers who successfully wrangled a large problem into a simple system are your weakest designers because what they designed is so small.
It's so weird to me that he was already 7 when Pearl Harbor was bombed .
“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)
I totally see him saying that. :-D 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 ab…
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
Earlier quoted context omitted.
I totally see him saying that. :-D 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 ab…
i think it's true that xp is for building a team with dependable performance, but i don't think that's true of incremental design in general, and i think what you're saying about 'discovering the best design' is actually backwards 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 u…
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
Earlier quoted context omitted.
i think it's true that xp is for building a team with dependable performance, but i don't think that's true of incremental design in general, and i think what you're saying about 'discovering the best design' is actually backwards 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 u…
What you say has been well known and that is why techniques like Barry Boehm's "Spiral Model" - https://en.wikipedia.org/wiki/Spiral_model were invented long ago. 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 exc…
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
Earlier quoted context omitted.
What you say has been well known and that is why techniques like Barry Boehm's "Spiral Model" - https://en.wikipedia.org/wiki/Spiral_model were invented long ago. 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 exc…
incremental design can indeed degenerate into no design, but i think the real intent of xp is continuous design, not no design. most of the core practices of xp are focused on extensibility and maintainability. it's difficult to do well, but 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', specifically because of the factor…
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 ...
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.
Earlier quoted context omitted.
incremental design can indeed degenerate into no design, but i think the real intent of xp is continuous design, not no design. most of the core practices of xp are focused on extensibility and maintainability. it's difficult to do well, but 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', specifically because of the factor…
> i think the real intent of xp is continuous design, 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 maintainabilit…
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