Thanks for making me feel dumb. :D
Mastering Programming (2016)
81–90 of 123 posts
Re: Mastering Programming (2016)
#82Re: Mastering Programming (2016)
#83Your regular reminder that Kent Beck was part of the Extreme Programming brain trust behind the massive failure that was the Chrysler Comprehensive Compensation System: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Programming advice from him and his cohorts (Ron Jeffries and Martin Fowler) should be regarded with several large grains of salt.
Thank you so much for sharing this. I finally have some ammo. As a .Net dev, I constantly encounter too many people who think Fowler is a programming prophet.
Re: Mastering Programming (2016)
#84Earlier quoted context omitted.
YAGNI is a conscious and iterative task prioritization process. From a Pareto perspective, it just means to focus on the 20% of functionality that provides 80% of the value first. That's not to say the other 80% of requests should be ignored. But instead well documented and groomed in a backlog.
In practice, YAGNI works out exactly how C3 ended up. Your architecture and design ends up myopic and short sighted, and gets overwhelmed by deferring complexity that could have been dealt with adequately early on, it is much harder to retrofit back onto an existing code base. Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and…
"You Are Gonna Need It" is the YANGI I live.
I also feel the same about "premature optimization," but that might just be due to my personality.
Re: Mastering Programming (2016)
#85I am always amazed at how some people can put very complex concepts into very simple words. It's an art that is often undervalued.
On the other hand, I'm not sure he succeeded on that front when communicating Agile or TDD. Arguably there are no works misconstrued more in the realm of computing than those. It may just be luck in this case – or perhaps a skill that has been honed over the years?
Re: Mastering Programming (2016)
#86Earlier quoted context omitted.
There is some discussion in C2 by the people involved about whether it was a failure or not: http://wiki.c2.com/?HighDisciplineMethodology I believe the characterization of C3 as a "failure" is because it wasn't able to deliver the goal (goal was paying 87000 people – it only reached about 9000), and was later discontinued for multiple reasons (some unrelated, like people leaving, the merger with Daimler). The claim…
C3 was, by any measure, an abject failure. It got only the very basics working and then died when it ran into the vast number of unspecified exceptional cases (gee, where have we heard that before ...) that needed to be handled. And then got cancelled and completely reverted. To then use such a failure as a marquee project demonstrating the supposed "superiority" of XP is unabashed chutzpah. Now, large IT projects ge…
> It got only the very basics working and then died when it ran into the vast number of unspecified exceptional cases (gee, where have we heard that before ...) that needed to be handled. And then got cancelled and completely reverted.
> To then use such a failure as a marquee project demonstrating the supposed "superiority" of XP is unabashed chutzpah.
> Now, large IT projects generally fail. So, XP is not wholly to blame.
One could argue that XP achieved a significantly better outcome than the typical project of that size. They didn't cause any big outages, and reached the end result of being cancelled and reverted much more quickly and cheaply than usual.
Re: Mastering Programming (2016)
#87Earlier quoted context omitted.
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.
Makes sense. Am I reading into your response if I assume you are not a fan of XP?
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.
Re: Mastering Programming (2016)
#88Your regular reminder that Kent Beck was part of the Extreme Programming brain trust behind the massive failure that was the Chrysler Comprehensive Compensation System: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Programming advice from him and his cohorts (Ron Jeffries and Martin Fowler) should be regarded with several large grains of salt.
These object-oriented "birth projects" were all pretty much deemed failures. NeXTStep by Steve Jobs, C3... Yet all these years later, the principles of OOP, and the companies built on them, outlived the politics that tried to squash them in the 90s.
OOP is a failure ... looked at through the lens of today.
Back then, OOP originally solved a very real problem--optimizing memory usage of bunches of objects that have mostly common behavior with just a few tweaks different from one another. It did pretty well at that at the expense of introducing some extraneous coupling and complexity.
And then memory got big and disk became SSD.
Now, programmers would rather burn extra memory, avoid pointer chasing (expensive on modern microprocessors), and ditch the extraneous coupling that introduces unnecessary complexity.
Re: Mastering Programming (2016)
#89Your regular reminder that Kent Beck was part of the Extreme Programming brain trust behind the massive failure that was the Chrysler Comprehensive Compensation System: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Programming advice from him and his cohorts (Ron Jeffries and Martin Fowler) should be regarded with several large grains of salt.
> Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we'll see... -- KentBeck
> So, I'm curious - does this represent a failure of XP? -- AnonymousCoward
> Sensitivity, certainly. But if the people who tell you what to do don't agree with the people who evaluate what you are doing, you're stuffed, XP or no XP. -- KentBeck
http://wiki.c2.com/?CthreeProjectTerminated
Between this and the Wikipedia article, it's not clear to me that the project failed due to XP practices.
Re: Mastering Programming (2016)
#90Earlier quoted context omitted.
YAGNI is about not implementing features until they are needed. It’s not about ignoring the complexities of the domain. You can adhere to the principle while still designing a system that acknowledges the complexities but defers implementation until it is needed.
I have no horse in this race but I believe what the other poster was saying is that you might not need it but you should still think about it and decide if you should factor it into your designs. YAGNI creates problems.
[deleted]