Re:Wolfenstein 3D secrets revealed by John Romero in lengthy...
by kqr on Saturday March 26, 2022 @11:05AM
(#30812462)
While you are technically correct and I agree completely, I think your emphasis on abstraction might lead to higher (or at least more variable) cycle times rather than lower.
It sounds like you're suggesting that one spends, say, 80 % of one's creativity coming up with general, abstract problems to tool for, and then 20 % of the creativity on finding ways to apply general tools. That absolutely works, I think, if you're fine with high variability in the time you spend between each release.
What I tried to suggest is that instead you spend 40 % of your creativity on finding abstract problems to tool for, and the other 60 % of your creativity in finding ways to apply your distinctly less general tools to new situations, despite their lack of generality.
What concerns me about the high-abstraction route is that people, in my experience, have a tendency to over-abstract. To try to predict every future use case ahead of time, instead of accepting their ignorance and building for ease of change.
That is why I want to emphasise modding non-general tools rather than future-proofing tools at the design stage. Because you can't know at the design stage in which direction future innovation will go.
It sounds like you're suggesting that one spends, say, 80 % of one's creativity coming up with general, abstract problems to tool for, and then 20 % of the creativity on finding ways to apply general tools. That absolutely works, I think, if you're fine with high variability in the time you spend between each release.
What I tried to suggest is that instead you spend 40 % of your creativity on finding abstract problems to tool for, and the other 60 % of your creativity in finding ways to apply your distinctly less general tools to new situations, despite their lack of generality.
What concerns me about the high-abstraction route is that people, in my experience, have a tendency to over-abstract. To try to predict every future use case ahead of time, instead of accepting their ignorance and building for ease of change.
That is why I want to emphasise modding non-general tools rather than future-proofing tools at the design stage. Because you can't know at the design stage in which direction future innovation will go.