Thread by @jub0bs

I'm only halfway through Bertrand Meyer's 2014 book, "Agile! The Good, the Hype and the Ugly", but it's already proven its worth as a lucid, unrestrained appraisal of #Agile principles and methodologies. Here are a few passages that resonated with me...

"#XP's insistence that [pair programming] should be the absolute rule [...] makes little sense conceptually, as it neglects the role of programmer personality (some excellent developers like to concentrate alone and will resent having to be paired) [...]"

"Starting any significant software project (anything beyond a couple of months and a couple of developers) without taking the time to write some basic document defining core requirements is professional malpractice."

"To invoke the changeability of requirements as a reason to reject upfront requirements makes no sense. [...] When you write an article, its structure will change as you go; most people still find it useful to start with a table of contents, knowing that it is not cast in stone."

"There is little meaningful difference between 'design' and 'architecture'. For clarity, the discussion will use 'design' for the process and 'architecture' for its result (then we do not need 'architect' as a verb)."

"#refactoring [...] has emerged as an important software engineering technique, but is not a replacement for sound upfront design; if an architecture is decent you can improve it, but refactored junk is still junk."

"The insistence on minimal software [...] leads to some of the most absurd and damaging contributions of #Agile methods."

"The downside of a strategy of 'building the simplest thing that can possibly work' is that if favors picking, at every stage, the low-hanging fruit: the features that can be implemented most easily, to produce a demoable result."

"[It is naïve] to expect that 'refactoring', once you have something that works partly, can solve any problems that remain. These problems can be very hard, for example a major performance issue that cannot be corrected without a complete redesign."

"To focus on the visible at the expense of the essential is irresponsible."

"[...] you must think hard and think early. So much for deciding as late as possible and building the system one feature at a time."

"The #Agile manifesto talks of 'welcoming' change, not just accepting it. This is an exaggeration. It is one thing to state that change is a normal phenomenon in software development, and quite another to start _hoping_ for more changes."

"[...] the fundamental issue governing change in software is architectural. Ease of change does not come out of thin air: it requires _designing the architecture for change_. Good textbooks teach you how, but such Big Upfront thinking is precisely what agilists reject."

"Whether the test is written before, during or immediately after matters less than the fundamental rule: _no code without test_." Meyer thinks along the same lines as @TotherAlistair, here. staging.cockburn.us/the-modern-pro…

"The principle of using #scenarios for requirements specification is one of the most widely practiced agile concepts, and one of the most damaging." Ouch! #Agile

"A specification is general: it says what should happen in all cases. A use case or #UserStory, like a test, is specific: it tells you what should happen in one case." This is reminiscent of the dichotomy between #PropertyBasedTesting and example-based testing. #Agile

And further in the book: "No amount of refactoring is going to correct a flawed architecture."

"[...] it would be fine if everyone would [...] refrain from sweeping absolutes. Open spaces are not the solution for all people and all times."

"If silence is 'always a bad thing', what of the reverse situation: a workplace where everyone is babbling all the time? It is just as alarming. A healthy environment [...] is one in which sometimes people talk and sometimes they silently read, or write, or just think."