4 ms·

Thanks for that video and channel. See what you mean about simple and accurate, strongly agree with the presenter calling it genius. Can't help but feel there i

Thanks for that video and channel. See what you mean about simple and accurate, strongly agree with the presenter calling it genius. Can't help but feel there is a strong lesson in there for software people.

krisoft 5y ago
> Can't help but feel there is a strong lesson in there for software people. Hmm, can you elaborate on that? What is the strong lesson for software people specifically? Don’t get me wrong it is a beautiful design, and I’m a big fan of flexure designes in general. There is this amazing open source project which uses similar flexure mechanisms for very accurate positioning of microscope samples: https://openflexure.org/ https://openflexure.org/ But I fail to see any obvious takeaways which would generalise to software development. Other than perhaps “Think and work on the same problem for a decade and more and you might find a compact and elegant solution.” Which is nice, when one has that luxury.
- ChrisMarshallNY 5y ago
  We tend to make complex solutions to simple problems. The thing about any problem, is that "the devil is in the details." It may seem simple, from a high level, but, once we start to "drill down" into the issue, the "rough edges" appear. At that point, we start to break out the baling wire and bubblegum, to kludge our original "graceful" design to meet the facts on the ground. It doesn't just happen for software. Hardware suffers from the same issue, but software makes it easy to start coding before modeling the requirements and context completely. I actually leverage this, in my own work. I call it "Evolutionary Design"[0]. It's not for the faint of heart, because a big part of it is recognizing when I'm rabbitholing, and tossing out what may be weeks of code, wholesale. I'm actually going through that process right now, with the app I'm developing. I'm working on the final feature set. [0] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... "There's always an easy solution to every human problem; Neat, plausible and wrong." "The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake." -- H. L. Mencken “When the map and the terrain disagree; believe the terrain.” -- Swiss Army Maxim
- aenis 5y ago
  The takeaways are limited, IMHO. Yes, in software engineering ingenious, simple, sometimes a bit crude solutions exist and can solve otherwise complex problems. More often than not, overly complicated, endless stacks of abstractions are developed to solve relatively trivial problems. But, software engineering is usually about maintaining something as part of a larger, dynamic, distributed system (comprised of humans, other tech) and reliance of brilliance is a limiting factor, since brilliant engineers rarely want to support their creations for years. With age, I am growing more and more tolerant of bloated, verbose, boring code that can be passed from one individual to another without too much trouble. I think the actuator is an equivalent of a very clever Perl one liner.

krisoft 5y ago

> Can't help but feel there is a strong lesson in there for software people. Hmm, can you elaborate on that? What is the strong lesson for software people specifically? Don’t get me wrong it is a beautiful design, and I’m a big fan of flexure designes in general. There is this amazing open source project which uses similar flexure mechanisms for very accurate positioning of microscope samples: https://openflexure.org/ https://openflexure.org/ But I fail to see any obvious takeaways which would generalise to software development. Other than perhaps “Think and work on the same problem for a decade and more and you might find a compact and elegant solution.” Which is nice, when one has that luxury.

ChrisMarshallNY 5y ago
We tend to make complex solutions to simple problems. The thing about any problem, is that "the devil is in the details." It may seem simple, from a high level, but, once we start to "drill down" into the issue, the "rough edges" appear. At that point, we start to break out the baling wire and bubblegum, to kludge our original "graceful" design to meet the facts on the ground. It doesn't just happen for software. Hardware suffers from the same issue, but software makes it easy to start coding before modeling the requirements and context completely. I actually leverage this, in my own work. I call it "Evolutionary Design"[0]. It's not for the faint of heart, because a big part of it is recognizing when I'm rabbitholing, and tossing out what may be weeks of code, wholesale. I'm actually going through that process right now, with the app I'm developing. I'm working on the final feature set. [0] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... "There's always an easy solution to every human problem; Neat, plausible and wrong." "The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake." -- H. L. Mencken “When the map and the terrain disagree; believe the terrain.” -- Swiss Army Maxim
aenis 5y ago
The takeaways are limited, IMHO. Yes, in software engineering ingenious, simple, sometimes a bit crude solutions exist and can solve otherwise complex problems. More often than not, overly complicated, endless stacks of abstractions are developed to solve relatively trivial problems. But, software engineering is usually about maintaining something as part of a larger, dynamic, distributed system (comprised of humans, other tech) and reliance of brilliance is a limiting factor, since brilliant engineers rarely want to support their creations for years. With age, I am growing more and more tolerant of bloated, verbose, boring code that can be passed from one individual to another without too much trouble. I think the actuator is an equivalent of a very clever Perl one liner.