4 ms·

I disagree with most of the article. The author states that the reason we start at the bottom is because "it feels good". This is false. We start at the bottom

I disagree with most of the article. The author states that the reason we start at the bottom is because "it feels good". This is false. We start at the bottom because that's what a product spec is. The product spec can impact any node but will mostly be at the bottom. So, we must start there and work backwards to figure out what engineering choices will meet that product spec. Second, the author talks about building "program families" instead of just a program. The problem with this concept is that it is essentially asking you to divine the future. Your success at divining in what way the program will change is what determines the success of this approach. That is to say, if you're in a space where you absolutely cannot predict in what way the requirements will change, the optional strategy is to just build for the requirements right now.

PH95VuimJjqBqy 3y ago
Not only that, but the phrase of "program families" is poor imo. The phrase he's looking for is "a class of programs", similar to the ideas that in diff EQ you don't derive a formula, you derive a class of formulas that you can then readily plug in values to get the specific formula you need. But also, his point about configuration creating slightly different programs is true, but modularity suffers from the exact same problem.
- Nevermark 3y ago
  For a phrase representing the highly unformalized concept of where a software project may go in the future relative to unpredictable customer, business, resource and developer needs, "family" seems appropriate. There is continuity, but not necessarily any other logical relationship being maintained. Sets of differential equations with specifiable constants have more in common with a compiler exposing customizable parameters, forming a "class" of behaviors. Or a parser compiler taking a grammer, and producing a well defined "class" of parsing algorithms.

PH95VuimJjqBqy 3y ago

Not only that, but the phrase of "program families" is poor imo. The phrase he's looking for is "a class of programs", similar to the ideas that in diff EQ you don't derive a formula, you derive a class of formulas that you can then readily plug in values to get the specific formula you need. But also, his point about configuration creating slightly different programs is true, but modularity suffers from the exact same problem.

Nevermark 3y ago
For a phrase representing the highly unformalized concept of where a software project may go in the future relative to unpredictable customer, business, resource and developer needs, "family" seems appropriate. There is continuity, but not necessarily any other logical relationship being maintained. Sets of differential equations with specifiable constants have more in common with a compiler exposing customizable parameters, forming a "class" of behaviors. Or a parser compiler taking a grammer, and producing a well defined "class" of parsing algorithms.