Live data from Hacker News

Uncle Bob and Silver Bullets

hillelwayne.com

221–228 of 228 posts

Re: Uncle Bob and Silver Bullets

#221

Earlier quoted context omitted.

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.

> 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. To his credit, Hillel is trying to evangelize (in general, not directly through the post linked) a particular tool (TLA+) whose creator (Leslie Lamport) wants to do exactly this. I don't know how big Hillel's employer is, but from what I understand it's n…

We have about ten engineers, so nowhere near the size where people consider formal methods "appropriate". Nonetheless it's still been incredibly useful for our work.

I'm a pretty huge evangelist of TLA+, but I don't think it's the silver bullet of software correctness. It just happens to be the tool I'm most familiar with and the one I thought could benefit most from a free guide. If people start widely using TLA+, I'll be ecstatic. If people ignore TLA+ but start widely using Alloy, I'll still be ecstatic. Software correctness is a really huge field and there's lots of really cool stuff in it!

Speaking of making methods more accessible, I'm working on a tutorial about Stateful Testing. Hypothesis (https://hypothesis.works) is an absolutely incredible property-based testing library for Python, and I think it could potentially make PBT a mainstream technique. One of the more niche features is that you can define a test state machine that runs by randomly selecting transitions rules and mutating your program state, then running assertions on the new state. It's really neat!

Re: Uncle Bob and Silver Bullets

#222

I think that automated testing is superior to any other tool/technique that we can use to avoid mistakes in programming. Can anyone argue with this? What is the alternative?

Static typing combined with functional programming is superior to automated testing, although the three are actually complementary, because automatic, property-based testing works better if you have type info (such that the library knows what values to generate) and referential transparency, because side effects can be awkward to specify as laws. So it is not a coincidence that Haskell developers have innovated testi…

QuickCheck is actually older than the TDD movement!

Re: Uncle Bob and Silver Bullets

#223

Earlier quoted context omitted.

I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.

A tool is short term, shallow, and goal-oriented. Building discipline and good practices permeates a person's life far more deeply than tools.

Banking on discipline in any human endeavour seems to be fool's errand. You will get more reliable results by improving the environment, systems and tools. This can be seen in how much checklists have improved the quality and reliability in fields like medicine. We are in a field where we can literally codify the checklists to enforce them.

Re: Uncle Bob and Silver Bullets

#224

Earlier quoted context omitted.

Agree with this. I like some of his ideas. But a problem I have(possibly of my perception) with uncle Bob is that he gets too aggressive. If you don't have X percent (100%) code coverage, then you are doing it wrong, you are not a craftsman, etc. Well, Dan North put things in perspective a bit- https://dannorth.net/2011/01/11/programming-is-not-a-craft/ The problem is dogma. And it keeps repeating. But probably this…

I have never told people that they must have 100% test coverage. Indeed, I tell them that 100% test coverage is impossible. What you are referring to is a statement I frequently make -- 100% coverage is the goal. It's an asymptotic goal, but it's still the goal. No lesser goal makes any sense.

> 100% coverage is the goal. It's an asymptotic goal, but it's still the goal

What is a goal then? A maximum? A desirable attribute?

I'd argue a fixed percentage target of any kind doesn't make sense, much like measuring productivity by lines of code.

Re: Uncle Bob and Silver Bullets

#225
post #127

Earlier quoted context omitted.

Having worked on many systems like this, I generally don't really consider it to be better. Most of them just introduced different edge case behavior than Hibernate. Though, I generally prefer a non-religious approach to ORM mapping anyway. Use Hibernate for the stuff that it is good at. If you find it awkward for some particular service, don't be afraid to grab a DB connection and do a bit of SQL (maybe even using H…

> Use Hibernate for the stuff that it is good at. Sure, but that's a bit circular. I find that a sensible default is to write the code to match the data, not abstract the data to fit the code. Because, if nothing else, you'll want to understand that data with another language or framework. If it's a one-off Java project that will get thrown away in a few months, whatever is fine, but most Java applications (especiall…

I would actually argue that raw SQL in Java has worked pretty poorly overall ever since it was introduced. The APIs have gotten better, and will probably continue to.

But you know what has consistently provided a nice abstraction that works really well for 90% of cases (even if you start with DML, as you should)? Hibernate :)

I've used plenty of homegrown frameworks, and they just never are quite what their originators crack them up to be.

Re: Uncle Bob and Silver Bullets

#226

I think Uncle Bob is way off the mark here. In Clean Code he hammered in the idea that unit tests form an automated specification of some software system under development. This was a decent idea at the time. So why on earth would he tell people not to use type-safe languages or tools for defining better, formal specifications? Probably because he has something to sell? We need better tools, processes, and "disciplin…

Well, that's not the _only_ reason. ;-)

Hah!

I have read your books and used some of that material to train several teams over the years to practice test-driven development. So thank you for the inspiration and drive.

Re: Uncle Bob and Silver Bullets

#227

After reading the post by Hillel Wayne I decided to read Uncle Bob's article that is mentioned in the post ( http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... ). After reading both posts, and after reading most of the comments on this thread, I have to admit that my inclination is in favor of Uncle Bob. I agree with most of the points Uncle Bob made in his blog post. Tools are not the answer. TDD is not…

[deleted]

Re: Uncle Bob and Silver Bullets

#228

After reading the post by Hillel Wayne I decided to read Uncle Bob's article that is mentioned in the post ( http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... ). After reading both posts, and after reading most of the comments on this thread, I have to admit that my inclination is in favor of Uncle Bob. I agree with most of the points Uncle Bob made in his blog post. Tools are not the answer. TDD is not…

I disagree. Neither of them is saying anything is "the answer". They are merely putting emphasis on different things. From that perspective, I would say that Uncle Bob is more wrong. It doesn't make sense to emphasise discipline before best practices. Discipline is about following through on things and avoiding short cuts. That means in order to have discipline, you first have to have a procedure you are meant to fol…

I agree that neither of them is saying anything is "the answer". I read my comment and don't believe I implied it either. What I'm stating is my opinion: For me the answer is to do the best I can, with the tools I have.

Never stop learning, always strive to improve my skills. And yes, it takes discipline.

Post reply on HN