Live data from Hacker News

Uncle Bob and Silver Bullets

hillelwayne.com

131–140 of 228 posts

Re: Uncle Bob and Silver Bullets

#131
I think the thing is that the we have a different level problem in software, that can't be solved by either "methodologies" or "patterns" 0r "discipline" or languages...

We have a learnability / teachability / knowledge transmission problems that always disguises itself as a technical problem... If you could simply "distill" and "transmit" the relevant design knowledge to the person requiring it under a ressonable amount of time most software quality problems would become trivial.

We supposedly do "knowledge work"... but we learn mostly from experience, like cooks or handcraft artisans or whatever, instead of how civil engineers or auto engineers do. (And I suspect the problems is not just immaturity of the field... it's more that "the space of possible solutions" in software architecture is so insanely big that there's no way to learn/label/teach what the engineers need to know... we have the requirements of engineering, but the infinite solutions space of mathematics... and training successful mathematicians is something we know we have no clue how to do... only here we also expect the "untrainables" to have the professional conduct of engineers coupled with the depth of though of philosophers.)

Re: Uncle Bob and Silver Bullets

#132
post #127

Earlier quoted context omitted.

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

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 (especially enterprise Java) aren't throwaway projects.

Do you know what works in pretty much every language? Do you know what will be supported in 30 years? SQL queries.

Hibernate is good at some things, but if we think in terms of product lifetimes and not sprints, I think SQL is a much lighter dependency.

Re: Uncle Bob and Silver Bullets

#133

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…

I agree with this comment. OTOH it's very hard to have and enforce discipline in commercial SW development in the US anyway. Managers just want solutions hacked out as quick as possible, so no real time for properly crafting solutions in most cases. Scrum etc. also drives this type of mindset.

Agreed Scrum RAD DSDM are not suitable for all software projects.

Re: Uncle Bob and Silver Bullets

#134

Earlier quoted context omitted.

I assume you've seen "Object-Relational Mapping is the Vietnam of Computer Science"? http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

ORM is like C++. SQLAlchemy is the best ORM I know of. You can use it lightly and map tables, migrations, and never go deep into the ORM "problem". Saves you a lot of effort doing SQL push-ups. Many projects doing OO end up building a worse ORM from scratch eventually.

> Many projects doing OO end up building a worse ORM from scratch eventually.

Sure, and lots of people end up implementing a lisp in C++. Doesn't necessarily mean they should just use a lisp instead. Usually it just means they should learn how to use their tools idiomatically.

Re: Uncle Bob and Silver Bullets

#135

Earlier quoted context omitted.

Personally I’d prefer my language to let me fuck up.

y tho. you can have safety and expressivity...

it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.

Re: Uncle Bob and Silver Bullets

#136

Earlier quoted context omitted.

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

It doesn't help that the common advice to securing a database application is "don't, it's too hard to secure databases, just write another application to talk to the database application, and secure that."

A database is just another application. SQL is just another Turing-complete programming language.

Re: Uncle Bob and Silver Bullets

#137

Uncle Bob (2017) I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands. Rich Hickey (2011) It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have t…

Disclosure: I didn't like the talk. In Uncle Bob's view, which I assume has some popularity, unit-tests are a form of software specification. It's informal as the specification can only test specific examples of behavior based on a determined state and the people responsible for its maintenance are the programmers. And if you're not disciplined enough with how you write these tests you end up in a situation where you…

Building houses is not the right analogy to building software, because the used techniques are known and most new buildings are going to be exactly like the millions of other buildings that came before it, even when speaking of sky-scrapers. There's very little innovation in it.

Building a new building is usually akin to copying/downloading software, only more expensive. Art is involved in designing buildings sometimes and there is some innovation for the engineers that want to break records, e.g. in building the world's tallest buildings or in building them faster, but I think those are a minority.

I don't think Rich Hickey missed the point at all. If I ever saw an actual software architect, then Rich Hickey is one.

I think you missed his point of view, because Rich Hickey is also the guy that helped create Clojure's Spec and is a proponent of property-based testing, which Clojure's Spec now enables.

In fact Rich Hickey, in "Simple Made Easy" and other presentations, likes to talk about about the need for upfront design, for carrying about the delivered artifact, for thinking deeply about architecture, for simplification. He's in no way proposing a napkin-driven approach, quite the opposite ;-)

Re: Uncle Bob and Silver Bullets

#138
post #89

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…

[deleted]

Re: Uncle Bob and Silver Bullets

#139

Here is the post this post is in response to: http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... I don’t interpret the original piece as saying any of these tools and techniques are not useful. I interpret it as saying average developer mindset needs to shape up. I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these t…

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

That's quite a common issue when you're trying to emphasize a specific point. Uncle Bob's trying to make software developers care about their craft. He seems dismissive of any other techniques, but I think that's because he really wants people who read his posts and watch his videos to understand that specific point. If you already understand that point, then you're not the audience he's trying to talk to, and you're free to enhance your craft with any tools you see fit, because you've got the foundations right.

Unless you understand that he's trying to teach people something that's really difficult to fully understand and implement on a daily basis, I don't think you'll be able to understand why he's so dismissive about anything else.

Post reply on HN