From experience the point number 3 is a huge source of problem. it tend to increase rigidity and fragility.
The thing is making code truly reusable is really difficult and costly. It require lot of experience, budget and commitment to make an API rather than just a program that solve a single problem. I speak of API on purpose. An API is fully backward compatible, fully documented (even if you don't like it), comes with tutorials and so on, deal with all corners cases (and has a defined and documented behavior for all). It also typically optimized for performance.
If you achieve that, your code is really usable, in particular you can reuse that code without severely affecting rigidity and fragility of your software.
On the contrary, reusing code without promoting such code as an API is sure to increase rigidity and fragility. Because the code is not truely generic. Because the code make some shortcut maybe, because the perf is not so great but was acceptable in the other use case. For lot of reason that code doesn't achieve the quality an API require. So it isn't really reusable.
I remember reading that a program something that managed to work if you provide it the right inputs/env typically cost 1 unit. This is like a prototype or a script to solve an issue. Then there is software. A program that is validated, handle lot of error case and is robust enough to do its job in variety of env. The cost of a program is 3 unit. Then there APIs, truely reusable code that is rock solid and you can struct and build software and programs on top of it. Like Java API, spring, hibernate or the win32 runtime. Because of all of this, the cost of an API is 10 unit.
I see that a great share of problems of rigidity and fragility come from tentative of reusability without really investing enough in it. when you aim for reusability, you should agree to pay the associated cost. Most of the time you or your management will not want to pay that cost. So it make much more sence to reuse existing and validated API, typically open source than try to make your own...
From experience the point number 3 is a huge source of problem. it tend to increase rigidity and fragility.
The thing is making code truly reusable is really difficult and costly. It require lot of experience, budget and commitment to make an API rather than just a program that solve a single problem. I speak of API on purpose. An API is fully backward compatible, fully documented (even if you don't like it), comes with tutorials and so on, deal with all corners cases (and has a defined and documented behavior for all). It also typically optimized for performance.
If you achieve that, your code is really usable, in particular you can reuse that code without severely affecting rigidity and fragility of your software.
On the contrary, reusing code without promoting such code as an API is sure to increase rigidity and fragility. Because the code is not truely generic. Because the code make some shortcut maybe, because the perf is not so great but was acceptable in the other use case. For lot of reason that code doesn't achieve the quality an API require. So it isn't really reusable.
I remember reading that a program something that managed to work if you provide it the right inputs/env typically cost 1 unit. This is like a prototype or a script to solve an issue. Then there is software. A program that is validated, handle lot of error case and is robust enough to do its job in variety of env. The cost of a program is 3 unit. Then there APIs, truely reusable code that is rock solid and you can struct and build software and programs on top of it. Like Java API, spring, hibernate or the win32 runtime. Because of all of this, the cost of an API is 10 unit.
I see that a great share of problems of rigidity and fragility come from tentative of reusability without really investing enough in it. when you aim for reusability, you should agree to pay the associated cost. Most of the time you or your management will not want to pay that cost. So it make much more sence to reuse existing and validated API, typically open source than try to make your own...
Thx for this perspective, I really like the analogies.