3 ms·

Sadly, alas -- not only are there plenty of ways that code written in typechecked/compiled languages can (despite these benefits) easily begin the irreversible

Sadly, alas -- not only are there plenty of ways that code written in typechecked/compiled languages can (despite these benefits) easily begin the irreversible slide into becoming unmaintainable (or otherwise high-maintenance) slop -- but many of the more popular choices for such languages seem almost expressly designed to facilitate this slide. Which also presents a risk to your "load-bearing" software (whatever that means). We get the theory and correctness parts. But in the trenches and on the ground, there are other factors to consider.

naikrovek 5y ago
I'm on the ground, too, you know. fighting different battles, I'm sure, but I'm fighting, same as everyone else. except I have something of a superpower that not everyone has: two and a half decades of hindsight. my experience tells me, without question, that smart development practices (which are never ever what you hear among the technological fetishists in this field, who chase newness and do not chase improvements) are almost always the ugliest and least structured up-front, and the most pleasant projects of all time by the time those projects are mature. there is no rule to guide you, other than to simply write what you need right now, and no more. when you need more, write more. Do not try to predict what you will need, because today is the day you are the least experienced you will be from this point onwards. you will be a better developer tomorrow. so write today only what you need today. tomorrow you will know more, need more, and you can add more, and fix what was already written by the less experienced you. there is no framework, no paradigm, no approach of any kind that creates good software (of any size) that does not evolve as the project itself evolves and as the developers evolve. none. and finally, the curse: when you're at an age no one listens to you, you will realize this as well.
- akhmatova 5y ago
  Totally agree with you there (except for the 3 percent of the time when actually we do want to apply predictive branching, as it were, and brace ourselves for tomorrow's need rather than simply today's. That is arguably how the future gets built, in fact. But that there are outlier cases doesn't invalidate the main point of the principle you cite, of course). The rest -- frameworks, methodologies -- are window dressing (or at best training wheels), mostly.

naikrovek 5y ago

I'm on the ground, too, you know. fighting different battles, I'm sure, but I'm fighting, same as everyone else. except I have something of a superpower that not everyone has: two and a half decades of hindsight. my experience tells me, without question, that smart development practices (which are never ever what you hear among the technological fetishists in this field, who chase newness and do not chase improvements) are almost always the ugliest and least structured up-front, and the most pleasant projects of all time by the time those projects are mature. there is no rule to guide you, other than to simply write what you need right now, and no more. when you need more, write more. Do not try to predict what you will need, because today is the day you are the least experienced you will be from this point onwards. you will be a better developer tomorrow. so write today only what you need today. tomorrow you will know more, need more, and you can add more, and fix what was already written by the less experienced you. there is no framework, no paradigm, no approach of any kind that creates good software (of any size) that does not evolve as the project itself evolves and as the developers evolve. none. and finally, the curse: when you're at an age no one listens to you, you will realize this as well.

akhmatova 5y ago
Totally agree with you there (except for the 3 percent of the time when actually we do want to apply predictive branching, as it were, and brace ourselves for tomorrow's need rather than simply today's. That is arguably how the future gets built, in fact. But that there are outlier cases doesn't invalidate the main point of the principle you cite, of course). The rest -- frameworks, methodologies -- are window dressing (or at best training wheels), mostly.