4 ms·

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

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.

jshen 9y ago
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. Edit: fixed a typo and some formatting.
- einrealist 9y ago
  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.
- ballenf 9y ago
  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.

jshen 9y ago

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. Edit: fixed a typo and some formatting.

einrealist 9y ago
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.
ballenf 9y ago
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.