What nobody really talks about is how the project was ultimately cancelled. Reasons for the flop include unclear requirements, and the customer representative resigning due to burnout. That's fine, though many XP proponents sell it as a panacea that lets you respond to any change.
It's just remarkable to me how everyone involved was able to bootstrap careers as thought leaders from a project that failed so bad that Chrysler ended up banning XP.
I had a long post written, and I've decided that it probably belongs in a blog post rather than a random Hacker News comment, so I deleted it. But I'll just say no, Twitter is absolutely not an XP success story.
There are a handful of interesting ideas wrapped in a self-help program. For example, the idea of testing can be useful, while rules like “all code should have tests,” and “you should always write tests first,” are just silly. I’m sure it’s worked for some people on some projects, but generalizing that to all software development is just charlatanism.
I think the point is that at some point, the "thought leaders" start to lose relevance when they're not day-to-day practitioners. I'm not saying it is or isn't true about Beck (I've always enjoyed listening to him speak), but is critical thinking we should apply to anyone.
That's not critical thinking though, it's fallacious thinking. Whether or not someone is a "thought leader" has no bearing on the quality of the article.
Would the article have gotten as much traction if it had been written anonymously? If there's an appeal to authority, then an evaluation is appropriate.
Why submit it like that, but to indicate to readers why this article is worth reading? HN guidelines say to submit the title as is, without additional qualifiers or commentary. (Fortunately, the mods updated it)
I can't speak for the person who posted it. Seems like it could have been an honest mistake to me.
An "appeal to authority" means something more specific (e.g. the logical fallacy "argument from authority") and this is not happening here.
The whole point I'm trying to make is that we should evaluate the writing based on its content. The person I originally responded to was dismissing it solely because of the person who wrote it (which ironically an ad hominem is a fallacy very similar to an appeal to authority but for the opposite reason).
look at any of the bullet points in the article. it's very hard to constructivly criticise any of them, they are all so vapid. typical of beck's writings.
Well if it's so hard to criticise them, that could be an indication that there is some truth in them.
> they are all so vapid
I like that he doesn't make sweeping statements. Because in software development, to quote another great author, there is no silver bullet.
That's not a popular story to tell when you're writing a book or speaking in a conference, people like to hear simple black and white statements. But the fact of the matter is, reality is much more nuanced.
I think it's more likely that if you can't find anything constructive to say about it, that maybe you don't have a valid argument (your original post was an ad hominem attack after all).
You are attacking the person's writing capability, implying that the article is not good because they wrote something before that you disagreed with. You're trying to argue semantics here, but it doesn't really matter because either way your argument is fallacious.
I think Martin has a lot more to answer for as far as the sorry state of software today goes. Watching his discussion with Casey Muratori on GitHub last year was great. Not many people saw it, but boy does he compare poorly to a truly capable and knowledgeable programmer - https://github.com/unclebob/cmuratori-discussion
I generally have a negative opinion of Martin, but did we read the same discussion? Martin was very gracious in letting many points slide (points where he was correct!), and was generously willing to end the conversation at a sort-of draw when it was clear that Muratori was not really prepared to discuss things at a detailed level (It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance, a la early C++, Martin realized this later and I think that was the first inkling that he was wasting his time).
Muratori was even wasting his time arguing against programmer time _in general_ is less valuable than machine time? And doesn't understand that LLVM is an extremely specialized piece of software, from which general software engineering practices should not be extracted?
> It was obvious to me from the start that Muratori thought "dynamic polymorphism" just meant deep hierarchies of inheritance
Inheritance hierarchies aren't exclusively what he meant though. Interfaces and the whole 'prefer composition over inheritance' style of programming has the same fundamental problem Muratori is getting at: both inherently constrain a program's structure for, what he argues (and I agree with), has no benefit to the program's performance or the programmer's time. In fact, he argues that the constraints imposed by the use of inheritance/interfaces only slow programmers down.
His raw device driver example, in pt2 of their conversation, illustrates the advantage of procedural code over inheritance/interfaces. His API requires users to provide a function pointer that will be called whenever an event is raised. This API user is expected to switch over the enum values that they care to implement. This design is better than an interface that requires its members to implement read(), and write() functions because it is both more performant (no vtable overhead + compilers can make more aggressive optimizations) and more flexible (a new event can be added to the enum without requiring all the old code to be updated if they don't need to handle the new event type).
I started reading this and honestly don’t see the part where he “compares poorly” against Muratori. And disclaimer, I know more about Casey and his work than I know about “Uncle Bob”. If anything, Bob managed to explain himself very well and defend his point of view, which is, “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no?
> “context matters and programmer cycles are more important than CPU cycles in the majority of contexts”. I think this is something we could all agree on, no?
I don’t think people agree on this (I don’t at least). I like the story falsely attributed to Steve Jobs about how saving a user 1 second will save hundreds of years or whatever. From that perspective, programmer cycles are way less important than CPU cycles because every CPU cycle you save has a multiplicative effect depending on how many users you serve. And how true is that today when you have thousands of large business apps depending on one cloud service provider. The compounding effects of saving CPU cycles in every level of the stack has never been higher than it is today.
I have watched his journey from early 90s days struggling with OO and C++, to all the nonsense of the 2000’s, and where he is today.
I looked at some of the small amount of publicly available code he has written, and it was frankly horrible. An example of somehow who shouts loud enough getting attention because he can shout longer than most.
Kent writes a lot about metacognitive skills that are notoriously difficult to put to language because they sound so mundane but are highly enlightening when internalized.
Meditation and insight are useful analogues here, they sound utterly mundane or obvious when written about, even in highly technical or mystical contexts like mahamudra because they operate on behavior and schemas below language.
I think Kent’s writing is useful as a pointing method: read what he says and watch how you undermine yourself during work. It’s easier said than done too because cognitively demanding tasks undermine metacognition.
I can’t seem to find the history of it, but it essentially means somethings a bit rubbish, bad, or crap.
Pants are typically underwear in Britain, we wear trousers (Jeans, chinos, suit trousers) over our pants (boxers, y-fronts, briefs) so probably not something you’d want to show off that much.
Thanks for the reference to pants. In US pants covers jeans, chinos, slacks. Shorts are well, shorts. Underwear is our boxers, briefs, tighty-whiteys, etc.
- "adjective. British slang. Not good; total crap; nonsense; rubbish; bad
"The first half of the movie was pants but I stayed until the end and it was actually a great film.""
The art of talking about nothing. Harari has this trait. He talks about nothing for an hour straight and enjoys when people comment on the bullshit. What a character trait. Whenever you see this pattern, you know the person is a shill.
