4 ms·

I totally see him saying that. :-D First, most software methodologies are for teams. Wirth himself was more concerned with the individual programmer. Second,

• kragen 3y ago
  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 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
  • rramadass 3y ago
    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 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 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 https://www.youtube.com/watch?v=ffkIQrq-m34
    • kragen 3y ago
      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 factors i explained in the grandparent comment 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