Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Programming (2016)

tidyfirst.substack.com

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Mastering Programming (2016)

#61

Post by GMoromisato »

pavel_lishin wrote: post #60
GMoromisato wrote: post #38

I was ready to crap all over this--I've seen so many of these kind of posts--but this was (IMHO) quite good. There's a ton of (as the kids say) alpha in each of the bullet points. I can't say that I practice all or most of these habits, but the points about "calling your shots" and "concrete hypotheses" resonate. For example, when I add a debugging printf/log, I always ask myself, "will this output invalidate one or…

> There's a ton of (as the kids say) alpha in each of the bullet points. Come on, I know I'm about to hit 40, but slang can't be evolving that fast! How am I supposed to be keeping up with all the kids?

Don't ask me! I don't have enough rizz to get included in those circles.

Re: Mastering Programming (2016)

#62

Post by bsder »

whstl wrote: post #58
doctor_eval wrote: post #56

Earlier quoted context omitted.

I haven’t heard of C3 before, but I’m a big fan of reading about software project failures, and I’m not a fan of every aspect of XP, so I was certainly curious about this. That said, the Wikipedia page neither supports nor refutes your assertion, and Fowler himself discusses C3’s failure here: https://martinfowler.com/bliki/C3.html Fowler refers to notes that don’t seem to be in the Wikipedia entry any more: “In part…

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 generally fail. So, XP is not wholly to blame.

However, the proponents of XP pushed it as superior silver bullet to navigate both the political and technical waters of software projects. The fact that C3 was such a spectacular failure simply demonstrates that XP really wasn't any different than any other methodology being pushed by people with an agenda.

Re: Mastering Programming (2016)

#63

Post by Scubabear68 »

bsder wrote: post #62
whstl wrote: post #58

Earlier 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…

A lot of the failure of XP was an assumption that all developers develop software the same way, and for all software teams XP’s tenants are optimal.

Practices like pair programming and TDD work on some instances, are absolutely terrible in others. The arrogance of the original XP folks was a hard core belief that they had found the silver bullet of software development, and then marketing it ruthlessly.

Re: Mastering Programming (2016)

#64

Post by hyggetrold »

sandofsky wrote: post #53
hyggetrold wrote: post #39

Earlier quoted context omitted.

I thought early Twitter took off in part with help from XP? My understanding was that Jack poached a lot of XP practitioners away from Pivotal Labs to help build both Twitter and Square?

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?

Re: Mastering Programming (2016)

#65

Post by Scubabear68 »

bsder wrote: post #54

Your 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.

Perhaps the biggest fail of XP and C3 was the YAGNI philosophy.

As it turns out, in many complex domains, you ARE going to need it, so you should factor that into your design sooner rather than later.

This is also why many consulting lead projects fail, because the developers do not understand the complexities of the domain.

Not everything is a CRUD website.

Re: Mastering Programming (2016)

#66

Post by cybrox »

GMoromisato wrote: post #38

I was ready to crap all over this--I've seen so many of these kind of posts--but this was (IMHO) quite good. There's a ton of (as the kids say) alpha in each of the bullet points. I can't say that I practice all or most of these habits, but the points about "calling your shots" and "concrete hypotheses" resonate. For example, when I add a debugging printf/log, I always ask myself, "will this output invalidate one or…

Agreed, these are surprisingly on point.

The flow of 80/15/5 is what true seniority looks like in my opinion.

Do a lot of the heavy lifting on a goal, explore valuable (and sometimes promising but with a stretch) avenues around that goal and then be able to document and articulate in a way that another person can grow into it while you venture forth into the next challenge.

Re: Mastering Programming (2016)

#67

Post by andrei_says_ »

cybrox wrote: post #66
GMoromisato wrote: post #38

I was ready to crap all over this--I've seen so many of these kind of posts--but this was (IMHO) quite good. There's a ton of (as the kids say) alpha in each of the bullet points. I can't say that I practice all or most of these habits, but the points about "calling your shots" and "concrete hypotheses" resonate. For example, when I add a debugging printf/log, I always ask myself, "will this output invalidate one or…

Agreed, these are surprisingly on point. The flow of 80/15/5 is what true seniority looks like in my opinion. Do a lot of the heavy lifting on a goal, explore valuable (and sometimes promising but with a stretch) avenues around that goal and then be able to document and articulate in a way that another person can grow into it while you venture forth into the next challenge.

Coincidentally these are the things I feel most enjoyable in my job, and I am good at doing them.

I will never accomplish perfection in coding. Much higher satisfaction in discovery and collaboration.

Re: Mastering Programming (2016)

#68

Post by enterprise_cog »

Scubabear68 wrote: post #65
bsder wrote: post #54

Your 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.

Perhaps the biggest fail of XP and C3 was the YAGNI philosophy. As it turns out, in many complex domains, you ARE going to need it, so you should factor that into your design sooner rather than later. This is also why many consulting lead projects fail, because the developers do not understand the complexities of the domain. Not everything is a CRUD website.

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.

Re: Mastering Programming (2016)

#69

Post by matchagaucho »

bsder wrote: post #54

Your 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.

Re: Mastering Programming (2016)

#70

Post by matchagaucho »

Scubabear68 wrote: post #65
bsder wrote: post #54

Your 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.

Perhaps the biggest fail of XP and C3 was the YAGNI philosophy. As it turns out, in many complex domains, you ARE going to need it, so you should factor that into your design sooner rather than later. This is also why many consulting lead projects fail, because the developers do not understand the complexities of the domain. Not everything is a CRUD website.

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.

Post reply on HN