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

91–100 of 123 posts

Re: Mastering Programming (2016)

#91

Post by melagonster »

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?

maybe tiktok is a resolution.

Re: Mastering Programming (2016)

#92

Post by randomdata »

PH95VuimJjqBqy wrote: post #74
enterprise_cog wrote: post #68

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

Developers aren't great at sharing nomenclature, but by what seems to be the most common definition, YAGNI refers to not going off and implementing something that is more fun to implement, but isn't needed right away (if ever). Focus on what you actually need to get your project to a desirable state.

It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should design your software to be as accommodating as possible, most notably by ensuring testing is core to your design to assist you when the time for change comes. The other poster you refer to and YAGNI seem to be in alignment.

Re: Mastering Programming (2016)

#93

Post by randomdata »

hirvi74 wrote: post #84
Scubabear68 wrote: post #77

Earlier quoted context omitted.

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.

If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress?

The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship software, it is understandable this is isn't much of a problem.

Although I'm not sure how applicable that really is today anyway. The tools have changed dramatically. Often you want to make your code as readable/debuggable as possible as that also gives the best chance for the compiler to find the optimizations. These days, if you try to get fancy, you'll probably make the performance worse.

Re: Mastering Programming (2016)

#94

Post by Hayatabad »

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.

[dead]

Re: Mastering Programming (2016)

#95

Post by Hayatabad »

bsder wrote: post #88
matchagaucho wrote: post #69

Earlier quoted context omitted.

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…

[dead]

Re: Mastering Programming (2016)

#96

Post by mikaraento »

yura wrote: post #89
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.

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

While C3 might not be strong evidence against XP neither should it be considered evidence _for_ XP.

Re: Mastering Programming (2016)

#97

Post by mrkeen »

_gabe_ wrote: post #49
elteto wrote: post #35

Earlier quoted context omitted.

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…

> “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 be…

This had a very narrow context - so you're right to push back on parent applying it generally.

But Martin was originally saying that a program with DI will not be as fast as a program without DI ... i.e., interfaces!

When was the last time you were writing a program and thought that putting a class behind an interface would slow things down too much?

Re: Mastering Programming (2016)

#98

Post by Silhouette »

whstl wrote: post #75
bsder wrote: post #62

Earlier quoted context omitted.

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…

I was trying not to make any judgement call, but I agree. To me there are worse things in the story, though: they tried to make User Stories and even customer-driven tests and ended up burning out the only customer that was able to do it. It's not only underwhelming compared to the silver bullet they were selling in conferences and books, but it required some unicorn customer that they couldn't replace. For years I s…

To me there are worse things in the story, though: they tried to make User Stories and even customer-driven tests and ended up burning out the only customer that was able to do it.

This is still a legitimate concern today with the "product owner" role that a lot of popular Agile processes rely on. In effect the whole premise of having a PO embedded within the team as the authority on requirements that are expected to change at any time means the entire software development process is built around a single human point of failure.

Re: Mastering Programming (2016)

#99

Post by Silhouette »

randomdata wrote: post #93
hirvi74 wrote: post #84

Earlier quoted context omitted.

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

If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress? The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship softwa…

If you subscribe to "You Are Gonna Need It", how do you ever get around to shipping software if you are always implementing the things that are fun, but unnecessary, and not focusing on the things that are needed to progress?

The point is that you aren't always implementing things that are unnecessary. You probably have a roadmap where you're pretty sure what you're going to be doing for the next few days and weeks and less sure as you look further ahead. Obviously you don't want to spend months building some over-engineered, over-architected monstrosity. But there are plenty of people out there who take YAGNI very literally and argue that you shouldn't implement anything you don't need right now. That's absurdly inefficient if you can guess with 80-90% accuracy what you're also going to need a month from now and you can save a lot of effort by implementing everything mostly right the first time and not repeatedly reworking code you've only just written over that time only to end up at the same place anyway.

Re: Mastering Programming (2016)

#100

Post by ozim »

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…

I see it is written by Kent Beck - so look him up because he is not your average blogspam wannabe but actually someone you could list as software development master.
Post reply on HN