4 ms·

> still don’t know if I understand what this presentation is about 1. The simplicity of a system or product is not the same as the ease with which it is built.

> still don’t know if I understand what this presentation is about 1. The simplicity of a system or product is not the same as the ease with which it is built. 2. Most developers, most of the time, default to optimizing for ease when building a product even when it conflicts with simplicity 3. Simplicity is a good proxy for reliability, maintainability, and modifiability, so if you value those a lot then you should seek simplicity over programmer convenience (in the cases where they are at odds).

mumblemumble 6y ago
I find the graph at the top of Sandi Metz's article "Breaking up the Behemoth" (https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemoth https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemot...) to be poignant. If you agree with her hypothesis, what it's basically saying is that a clean design tends to feel like much more work early on. And she goes on to suggest that early on, it's best to focus on ease, and extract a simpler design later, when you have a clearer grasp of the problem domain. Personally, if I disagree, it's because I think her axes are wrong. It's not functionality vs. time, it's cumulative effort vs. functionality. Where that distinction matters is that her graph subtly implies that you'll keep working on the software at a more-or-less steady pace, indefinitely. This suggests that there will always be a point where it's time to stop and work out a simple design. If it's effort vs. functionality, on the other hand, that leaves open the possibility that the project will be abandoned or put into maintenance mode long before you hit that design payoff threshold. (This would also imply that, as the maintainer of a programming language ecosystem and a database product that are meant to be used over and over again, Rich Hickey is looking at a different cost/benefit equation from those of us who are working on a bunch of smaller, limited-domain tools. My own hand-coded data structures are nowhere near as thoroughly engineered as Clojure's collections API, nor should they be.)

mumblemumble 6y ago

I find the graph at the top of Sandi Metz's article "Breaking up the Behemoth" (https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemoth https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemot...) to be poignant. If you agree with her hypothesis, what it's basically saying is that a clean design tends to feel like much more work early on. And she goes on to suggest that early on, it's best to focus on ease, and extract a simpler design later, when you have a clearer grasp of the problem domain. Personally, if I disagree, it's because I think her axes are wrong. It's not functionality vs. time, it's cumulative effort vs. functionality. Where that distinction matters is that her graph subtly implies that you'll keep working on the software at a more-or-less steady pace, indefinitely. This suggests that there will always be a point where it's time to stop and work out a simple design. If it's effort vs. functionality, on the other hand, that leaves open the possibility that the project will be abandoned or put into maintenance mode long before you hit that design payoff threshold. (This would also imply that, as the maintainer of a programming language ecosystem and a database product that are meant to be used over and over again, Rich Hickey is looking at a different cost/benefit equation from those of us who are working on a bunch of smaller, limited-domain tools. My own hand-coded data structures are nowhere near as thoroughly engineered as Clojure's collections API, nor should they be.)