When designing anything new: Build one to throw away, or at least be prepared to (sunk cost avoidance). This one is rather controversial, with people arguing that Agile Development/RAD make this unnecessary. However, if you notice how often a major OSS project is redesigned way late in the game because the original architectural and design decisions no longer apply, you might as well plan for it in advance.
Thanks for introducing me to the IFR. I now have a card (amongst many) on my bulletin board saying
“The ideal system -
Occupies no space
Weighs nothing
Takes no labor to implement
Requires no maintenance
Delivers benefit without harm
And most importantly
Does not exist”
If you constantly invent systems, this is a very useful reminder to ask yourself whether the system actually gives greater utility than it’s encumbrance.
It’s interesting how the heuristic that makes you get better as a programmer/engineer (deliberately attack hard problems) is simultaneously a terrible one to apply when doing anything serious...
Yep, though it becomes less surprising when you consider that if we didn’t have any reason to attack hard problems, we wouldn’t need a heuristic to tell us not to. We don’t need a heuristic to remind us to not eat sand.
Programming, engineering, visual art, music, writing, it’s all similar. You do a lot of studies where you capture things in intricate and intimate detail, but when you go to make a product for a purpose, that history of studying tells you what to leave out to build a harmonious and compelling system.
Sculpture is probably a good metaphor for it.
Something in my brain really wants me to bring up Sturgeon’s Law here, so there it is :)
When evaluating a [scientific] claim: Extraordinary claims require extraordinary evidence. This is basic Bayesianism, without the calculations. For example, if a preprint is called Solution to the cosmological constant problem, one glance at the abstract is sufficient to dismiss it with high confidence.
When designing software (or anything else): The cheapest, fastest, and most reliable components of a computer system are those that aren’t there. Specifically, this means ruthlessly pruning my original design, until only the necessary functional parts remain. The Ideal Final Result approach is quite useful there.
When designing anything new: Build one to throw away, or at least be prepared to (sunk cost avoidance). This one is rather controversial, with people arguing that Agile Development/RAD make this unnecessary. However, if you notice how often a major OSS project is redesigned way late in the game because the original architectural and design decisions no longer apply, you might as well plan for it in advance.
Thanks for introducing me to the IFR. I now have a card (amongst many) on my bulletin board saying
If you constantly invent systems, this is a very useful reminder to ask yourself whether the system actually gives greater utility than it’s encumbrance.
It’s interesting how the heuristic that makes you get better as a programmer/engineer (deliberately attack hard problems) is simultaneously a terrible one to apply when doing anything serious...
Yep, though it becomes less surprising when you consider that if we didn’t have any reason to attack hard problems, we wouldn’t need a heuristic to tell us not to. We don’t need a heuristic to remind us to not eat sand.
Programming, engineering, visual art, music, writing, it’s all similar. You do a lot of studies where you capture things in intricate and intimate detail, but when you go to make a product for a purpose, that history of studying tells you what to leave out to build a harmonious and compelling system.
Sculpture is probably a good metaphor for it.
Something in my brain really wants me to bring up Sturgeon’s Law here, so there it is :)