2 ms·

What you are describing may say more about the problem definition than the rate of change. If the software will only be used in certain limited situations, then

What you are describing may say more about the problem definition than the rate of change. If the software will only be used in certain limited situations, then you can make a bunch of assumptions and assemble the solution from spare parts. As long as your assumptions hold everything is fine. When the assumptions fail, someone will tell you, and you can rewrite it with the new assumptions in mind. But some software might be used in a lot of strange environments with strange inputs. A lot of effort needs to be spent trying to clarify and improve semantic and performance edge cases. Using libraries here is not necessarily helpful because sometimes you spend more time working around the edge cases in the library than you would just re-implementing it. I recently re-implemented a minheap even though there was already a library readily available, because the library assumed pointer-width types and I needed it to support longs. On my machine, a pointer and a long are the same length, but that's not guaranteed.

geofft 7y ago
Regardless of environment, good software engineering (where by "software engineering" I mean "the process of producing code that continues to do useful things over time") requires a feedback loop from how the software is being used in production back to the developers. If your assumptions are failing, and you know about it, then you can deliver new code to match the new assumptions, either by rewriting it or by modifying it as makes sense. If your assumptions are failing and you don't know about it, you're in a terrible position. You can make further assumptions about which of your assumptions might fail (e.g., "the software is being compiled on a machine where a long is longer than a pointer") and which won't, but those are again assumptions - you don't know what changes you haven't thought about might come down the pipe (e.g., "the software is being translated to JavaScript, which has no longs, only floating point" or even "there's now a requirement to use a stable sort, so a heap is out of the question"). It's not at all clear that building rigid, well-armored software and throwing over the wall can even work. If at all possible, effort is better spent closing the feedback loop.

geofft 7y ago

Regardless of environment, good software engineering (where by "software engineering" I mean "the process of producing code that continues to do useful things over time") requires a feedback loop from how the software is being used in production back to the developers. If your assumptions are failing, and you know about it, then you can deliver new code to match the new assumptions, either by rewriting it or by modifying it as makes sense. If your assumptions are failing and you don't know about it, you're in a terrible position. You can make further assumptions about which of your assumptions might fail (e.g., "the software is being compiled on a machine where a long is longer than a pointer") and which won't, but those are again assumptions - you don't know what changes you haven't thought about might come down the pipe (e.g., "the software is being translated to JavaScript, which has no longs, only floating point" or even "there's now a requirement to use a stable sort, so a heap is out of the question"). It's not at all clear that building rigid, well-armored software and throwing over the wall can even work. If at all possible, effort is better spent closing the feedback loop.