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

Uncle Bob and Silver Bullets

hillelwayne.com

Post reply on HN
Print view View original

71–80 of 228 posts

Re: Uncle Bob and Silver Bullets

#71

Post by lomnakkus »

falcolas wrote: post #48
tom_mellior wrote: post #33

Earlier quoted context omitted.

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy…

> All the tools do is enforce a loop of compile -> make compiler happy -> compile.

Sorry, this is nonsense. Tools can eliminate whole classes of bugs from ever happening. I will never have a null pointer exception in a Haskell program, for example[1].

I'm not so sure what's so difficult to understand about this.

[1] Alright, if we're being extremely nitpicky, it's possible to do really weird things with various language extensions which could conceivably cause similar things, but a) those are opt-in, and b) very rarely necessary, if ever except in the implementation of the runtime/language itself. They can also be localized per-module such that you know what code to be extra careful about.

Re: Uncle Bob and Silver Bullets

#72

Post by NumberSix »

Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small potential non-monopoly competitors to adopt these slow, expensive, bureaucratic methods that smaller firms cannot afford (they run out of money trying to create perfect software instead of software that works and gets the job done).

Re: Uncle Bob and Silver Bullets

#73

Post by a-saleh »

falcolas wrote: post #48
tom_mellior wrote: post #33

Earlier quoted context omitted.

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy…

There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful?

And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work.

I still think that checks I put in place for myself help me more than they make me more lax.

Re: Uncle Bob and Silver Bullets

#74

Post by eradicatethots »

gregmac wrote: post #59
wasted_intel wrote: post #51

Earlier quoted context omitted.

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles". If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.

I don’t see why we should make this a requirement of every programmer.

Re: Uncle Bob and Silver Bullets

#75

Post by mannykannot »

falcolas wrote: post #48
tom_mellior wrote: post #33

Earlier quoted context omitted.

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy…

Some people may have those attitudes, but if so, then they are demonstrating a lack of discipline. The intended purpose of tools is not to enforce discipline, but to enable disciplined people to do a better job.

Re: Uncle Bob and Silver Bullets

#76

Post by chrisseaton »

eesmith wrote: post #62
chrisseaton wrote: post #14

Earlier quoted context omitted.

There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…

It is not reasonable of you to ask unless you've made a reasonable effort to look for their software and failed. Robert Martin's best known open source software contributions are for FitNesse, which is reasonably well known in the testing world. https://en.wikipedia.org/wiki/FitNesse Tell me, have you read the Space Shuttle control software? There are dozens of not hundreds of papers about NASA's development process.…

Sorry I didn't really mean about reviewing the code - I meant being able to see the successful project.

I listen to Torvalds when he talks about how to write his software, because his software is a massive success.

I'd listen to NASA because their missions were a success.

Why should I listen to other people like Robert Martin? I had seen FitNesse in the past, and while I'm sure it's a useful and well-written bit of software, I don't anyone would remotely describe it a particularly notable success. Why would I listen to his ideas more than anyone else who's written a testing framework that some people use?

Re: Uncle Bob and Silver Bullets

#77

Post by endorphone »

From the original post that is being replied to-

"The author did not interview software experts like Kent Beck, or Ward Cunningham, or Martin Fowler."

I mean no slight, but are Beck and Fowler really the experts of the field?

This is akin to the relationship guru who has been through three divorces -- often just declaring yourself an expert fools enough people into thinking you are.

Re: Uncle Bob and Silver Bullets

#78

Post by timgebrally »

NumberSix wrote: post #72

Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small p…

Perhaps if the methods are sound (even if expensive) then someone can step up and make tooling or refine them so the methods are more accessible to smaller firms. Uncle Bob's opinion's might be discouraging people from exploring them and finding ways to drive down the cost of adopting these better methods.

Re: Uncle Bob and Silver Bullets

#79

Post by adamlett »

zbentley wrote: post #9

I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel says, and can be used to mitigate risk. The key word there is mitigate , though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists. I think th…

I think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems

I think you’re on to something here, but you’re not all the way there. I think “lack of discipline” is such an unsatisfactory explanation for anything, and almost never the root cause of any problems, as you claim in your first paragraph. The reason it unsatisfactory is that it leaves us with no other remedy than to try harder. But if the root cause is systemic, then merely trying harder is bound to fail. If we are to gain any insights, we have to look closely at the systemic issues that manifest themselves as a lack of discipline. Saying that the cause of undisciplined individuals is an undisciplined culture doesn’t really get us anywhere. We have to understand why a culture can get that way. What it often comes down to in my experience, are incentive structures inside or outside of that company that have negative side effects or are downright dysfunctional. Sometimes you can fix them, other times you just have to accept them and live with them.

Re: Uncle Bob and Silver Bullets

#80

Post by eradicatethots »

a-saleh wrote: post #73
falcolas wrote: post #48

Earlier quoted context omitted.

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy…

There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful? And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work. I still think that checks I put in place for myself help me more than they make me more lax.

I don’t get why being lax is a bad thing lol. You’re not being lax randomly, you’re being lax because you learned that empirically you can afford it. Instead of wasting that energy on whatever discipline you used to have to apply, you can spend it on something of value. I don’t think it’s smart to get upset about life getting easier.
Post reply on HN