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

91–100 of 228 posts

Re: Uncle Bob and Silver Bullets

#91

Post by mannykannot »

bad_user wrote: post #63

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…

Martin has built up a large following of acolytes, some of whom are very active wherever software development is discussed, in a very dogmatic way (such as the guys for whom TDD is the one true solution to every problem.) He has encouraged this through his didactic style of writing, which focuses on a few of the most basic faults in current development practice, and elevates them to being the roots of all evil, without any regard to the problems that you will run into once you have these surmounted.

Re: Uncle Bob and Silver Bullets

#92

Post by eric_b »

I agree with the author of the article to an extent - there's lots of things about Uncle Bob's advice I don't care for. But...

I agree with Uncle Bob's take that discipline is lacking in software development today. It's not that people won't make mistakes if they are more disciplined - of course they will - but it's the kind of mistakes people are making that might change. I see code written every day that, when I give even a cursory glance to the PR, I can tell there are issues. The developer didn't even do the barest due diligence to make sure they didn't break things.

Formal verification and other software correctness tools can be great in the right circumstance. I think anyone doing life-critical software should be using something above and beyond the basics.

But, for most projects I see - formal verification isn't really a solution to quality issues. Having developers who give a damn and have a little paranoia and pessimism ("how is this thing going to fail on me?") would do 100 times more for the outcomes. In my mind the best code is the kind you didn't write, and the best infrastructure is the kind you didn't need to stand up, and the best distributed system is no distributed system.

Re: Uncle Bob and Silver Bullets

#93

Post by gyani95 »

thomascgalvin wrote: post #87
bad_user wrote: post #63

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…

> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ... My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google. I've also found that the ability to swap databases quickly is almost totally unimportant. 10…

How do you make sure that what you are writing is secure?

Re: Uncle Bob and Silver Bullets

#94

Post by mannykannot »

thomascgalvin wrote: post #87
bad_user wrote: post #63

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…

> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ... My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google. I've also found that the ability to swap databases quickly is almost totally unimportant. 10…

I think every commercial system that I have worked on has had a database abstraction layer of some form, ignoring the fact that an RDBMS with SQL was a better abstraction layer than what they came up with.

Re: Uncle Bob and Silver Bullets

#95

Post by tptacek »

chrisseaton wrote: post #90
tptacek wrote: post #36

Earlier quoted context omitted.

No, Spolsky didn't lead Excel development. He was a PM. I happen to like Spolsky a lot but most of the career success we've actually seen from him is managerial, which is not unimportant, but it's not the same as being a dev lead on Excel. On the other hand, Spolsky's programming advice is much more broad-spectrum and rooted in common sense. I'm not sure you've ever seen Spolsky dismiss a whole category of languages…

Isn't the PM the one who leads project? (I don't work in a team that uses these terms so genuinely asking.)

A product manager generally owns the spec for a product, but doesn't lead development of it.

(Microsoft has a more complicated PM scheme with I think two different kinds of PMs? So I can't speak to exactly what Spolsky's role was there. It wasn't a small role, but no, I don't think he led Excel development.)

Re: Uncle Bob and Silver Bullets

#96

Post by oblio »

_wc0m wrote: post #89
bad_user wrote: post #63

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…

Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. Now, ask yourself why these defects happen too often. If your answer is that our languages don’t preve…

Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U

My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)

Re: Uncle Bob and Silver Bullets

#97

Post by sanderjd »

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…

I can attest: I wrote Ruby for many years, recently I've only been writing in languages with much stronger static analysis capabilities. I had to be much more disciplined when writing and reviewing Ruby code. Inevitably, I slipped up frequently in both disciplines, resulting in lots of bugs in the software and a chronic nagging worry in my psyche. I don't need to be as disciplined now, but I'm creating fewer bugs and sleeping better. I feel that these are good things and much more important than a theoretical concern about it making me "more lax". This is just my experience, your mileage may vary, etc...

Re: Uncle Bob and Silver Bullets

#98

Post by Chris2048 »

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.

> a successful compile means no bugs

Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption.

Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..

Re: Uncle Bob and Silver Bullets

#99

Post by megaman22 »

taneq wrote: post #4
neilwilson wrote: post #3

The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…

I don't get why automated testing is a "domain specific type system checker". Not saying it's not, I just don't get it. Maybe that's because my automated tests are pretty free-form and tend to be more about throwing mud at an algorithm and seeing if the results stick. Your last line is bang on, though. We build a system, and a compiler (or processor) for that system. It doesn't matter if everything is "data driven" i…

I can see that label applying if you're using a language that has weak dynamic typing, so that you have to be checking all manner of crap that the compiler should flag for you. Like Python and JS unit tests suites I've seen too many of.

Re: Uncle Bob and Silver Bullets

#100

Post by Chris2048 »

falcolas wrote: post #85
gregmac wrote: post #59

Earlier quoted context omitted.

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.

Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.

> relying on the tooling instead of critical thinking

If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".

Post reply on HN