I think people like the sound of the ideas he's espousing in "Simple made easy", but toward he has some pretty specific examples of complexity that are often ignored. Like, I've worked with people who would fervently recommend the talk, but still love for-loops.
I suppose. But if you're talking about keeping things simple and not complecting them, but then you go around doing just that... what are you really talking about, you know?
I meditate. My goal is to be more at ease with my thoughts. I still get anxious and confused, but that doesn't make the effort any less worthwhile. Same thing with simplicity: it's a habit that you build into your work by degrees over time. We'll always come up short and have our blind spots, but that doesn't invalidate the worth of the effort.
I like Hickey and Clojure. But part of me feels sad and pessimistic when I think him and his project. The stuff he was working on at the beginning, although new to most people who were exposed to it, wasn't new to the software engineering community at large. And now it's a decade later and it still feels like it hasn't progressed as far as it aught to given how much time and how many man-hours have been spent on it.
Doing things right is hard and it often requires more time. My feeling is that the majority of software engineers are less interested in detail and doing things right and more interested in getting things done. And most environments encourage to get things done (time to market) with all the bad results (broken / insecure software, bad architecture). In pure functional languages doing what's right is often the only way to get things done. This is why there is a smaller audience to Clojure or Haskell.
It's dreadful to explain the average engineer (in my environment) basic principles of design and architecture over and over again (like what is an URI / URN / URL, or why should I use Strings as general identifiers rather than exposing the numeric value from the database to the outside) just to see them dismissing everything in the next second. Now, when I tell them to look into Clojure or Haskell just to learn something.... No I don't do that. Its sad.
But Kudos to Rich. I find it is more important that he is talking / lecturing about basic principles of software design and architecture and using Clojure as an example, despite Clojure's actual success.
When you say "doing things right", what does "right" mean exactly? I see people say this a lot, and I think that I do things "right", but my definition of "right" is very different from yours.
My definition of "right", create the most value at the lowest cost.
My assumption is that when you say "right" you mean, "done in a way that produces the fewest bugs". If this is true, there is no consideration of the costs in your definition which seems wrong to me. At this point I usually hear people who make similar claims to you respond by saying, our "right" way doesn't cost more, or even costs less.
I don't think this is true, and here's why. If it's true, your "right" way would produce better software at the same price. If that's true one of the following would also be true.
1. companies doing it the "right" way would, on average, beat companies doing it the not "right" way. I have seen no evidence of this, in fact the opposite seems true.
2. Having a lower bug count has no bearing on the success of companies so there is no correlation between the "right" way and the not "right way. I doubt this is true, but I could be wrong.
What I think is true is that your "right" way costs significantly more, and the market in most cases has shown time and again that it's not worth the cost.
I don't know that financial success is the be-all end-all measuring stick that I want to measure my code against. It is important because I also like to eat and sleep in a bed. But most any talented engineers could make vastly more money doing shady stuff. But very few do and that's a fact that I find rather amazing and gives me great pride in this profession.
Point is simply that I don't want to throw out all measures of quality of craftsmanship except financial.
I love Bob Martin's line that the dirty secret of programmers is that we'd still do it whether they paid us or not.
The right thing can be architectural choices in the macro and micro architecture of software that support qualities like stability, security, extensibility, interoperability and some other -bilities.
From what I experience is that many engineers don't take or don't have the time to think details through that are hard to change, later. I find functional languages to be less forgiving to bad design choices. So that's why I assume that functional languages have a smaller audience.
Of course, what's right is an abstract concept. But when you see bad software, you will know it. If a company can sell bad software, they may be "right", but they also build on risks that counter that view.
Edit: Btw. I don't expect software design to be 100% perfect, as long as the output is 100% correct. But every good design decision helps to build good stuff.
Then 6 months later you are still thinking about points he made in the talk.