4 ms·

Is it truly inevitable that a successful product will be rewritten? That's so wasteful that it seems irresponsible to let personal preference or emotional inves

Is it truly inevitable that a successful product will be rewritten? That's so wasteful that it seems irresponsible to let personal preference or emotional investment influence foundational decisions that might later prove wrong, requiring a rewrite. We should do our best to make such decisions carefully, dispassionately, and scientifically.

jacobr1 11y ago
The inevitability at this time seems to be that the desired function of large, successful systems will evolve over time. This is the root cause of larger system rewrites being so common and (at this time) largely inevitable. But that is also the appeal of strong subsystems that last and can evolve. Language runtimes, libraries, infrastructure components like databases. The can largely persist, but their suitability to various systems will shift as the system themselves change. One must consider that many approaches, even if better for the long-run would have near term costs in terms of additional effort, or training, operational support or even hardware needs. > That's so wasteful that it seems irresponsible to let personal preference or emotional investment influence foundational decisions that might later prove wrong, requiring a rewrite Not so, since it is likely the case that the requirements and system's function will change, the primary objective is the efficient production of first working version. Personal productivity, satisfaction and good team dynamics probably trump most technical consideration beyond broad strokes (writing for web in assembly is probably a bad idea, but django vs. rails vs. go microservies is probably moot). Furthermore, one must consider the corollary to the initial presumption: most new projects either aren't successful or aren't long lived. So while if you have strong evidence that a system will be successful and long lived further investment in technical deliberation in making the choice of platform, toolset and architecture would be warranted - it is much more likely no such evidence exists. And therefore the initial investment is the only one likely to be made, so longer term confederations matter not (again beyond some basics and near universal best practices).
nostrademons 11y ago
When a successful software system is rewritten in another language, that doesn't mean the original decision was "proven wrong". It means that conditions have changed. The original language was usually absolutely right for the conditions that existed when the original software was written, otherwise it wouldn't have become successful. Those conditions often include severe resource constraints; small teams; small numbers of un-demanding customers; and extreme uncertainty about exactly what the product will do. When the product becomes successful, the certainty about what it will do goes up, available resources go up, team sizes get bigger, and customers get more demanding. The world changes around you as well: new languages are invented, new frameworks come out, customers request different integrations. All of these impose different constraints on the software architecture. (Incidentally, I suspect that failure to recognize the time-dependence and context-dependence of decision making is behind most career missteps. That old grizzled programmer who insists on using COBOL and DB2 on record-oriented flat files? He's following best practices, he's just following best practices from the 1960s. Similarly, many workers who assumed companies would honor their pension agreements and no-layoff culture were in for a rude shock when executives made decisions based on what is necessary now and fucked over the people who worked hard for them then.)

jacobr1 11y ago

The inevitability at this time seems to be that the desired function of large, successful systems will evolve over time. This is the root cause of larger system rewrites being so common and (at this time) largely inevitable. But that is also the appeal of strong subsystems that last and can evolve. Language runtimes, libraries, infrastructure components like databases. The can largely persist, but their suitability to various systems will shift as the system themselves change. One must consider that many approaches, even if better for the long-run would have near term costs in terms of additional effort, or training, operational support or even hardware needs. > That's so wasteful that it seems irresponsible to let personal preference or emotional investment influence foundational decisions that might later prove wrong, requiring a rewrite Not so, since it is likely the case that the requirements and system's function will change, the primary objective is the efficient production of first working version. Personal productivity, satisfaction and good team dynamics probably trump most technical consideration beyond broad strokes (writing for web in assembly is probably a bad idea, but django vs. rails vs. go microservies is probably moot). Furthermore, one must consider the corollary to the initial presumption: most new projects either aren't successful or aren't long lived. So while if you have strong evidence that a system will be successful and long lived further investment in technical deliberation in making the choice of platform, toolset and architecture would be warranted - it is much more likely no such evidence exists. And therefore the initial investment is the only one likely to be made, so longer term confederations matter not (again beyond some basics and near universal best practices).

nostrademons 11y ago

When a successful software system is rewritten in another language, that doesn't mean the original decision was "proven wrong". It means that conditions have changed. The original language was usually absolutely right for the conditions that existed when the original software was written, otherwise it wouldn't have become successful. Those conditions often include severe resource constraints; small teams; small numbers of un-demanding customers; and extreme uncertainty about exactly what the product will do. When the product becomes successful, the certainty about what it will do goes up, available resources go up, team sizes get bigger, and customers get more demanding. The world changes around you as well: new languages are invented, new frameworks come out, customers request different integrations. All of these impose different constraints on the software architecture. (Incidentally, I suspect that failure to recognize the time-dependence and context-dependence of decision making is behind most career missteps. That old grizzled programmer who insists on using COBOL and DB2 on record-oriented flat files? He's following best practices, he's just following best practices from the 1960s. Similarly, many workers who assumed companies would honor their pension agreements and no-layoff culture were in for a rude shock when executives made decisions based on what is necessary now and fucked over the people who worked hard for them then.)