# Care About Risks Why should you care about risks with reuse? Because, these risks are real not made up and can make the difference between success and failure for your development effort. Here are a few risks that spring to mind: * Needless complexity * Inflexible design/will cost too much to modify * Domain irrelevance * Inadequate documentation/training/awareness * Ability to meet deadlines/dates (schedule risk) * Increased development, testing, and maintenance costs * Pursuit of technical elegance/architectural purity These are not all the risks with reuse but the major ones that I have come across. Now, what do you with these? You do what leaders do and that is address them head on. Instead of sulking about these you should plan and execute mitigation steps for these. [Refactoring](http://www.refactoring.com/) is the fundamental technique for addressing these risks! Take another look at the above list. You can use refactoring to handle most of these if not all of them. * Needless complexity – build only what you absolutely need with just enough abstraction. Refactor needless layers and abstractions. Keep things as simple as possible. * Inflexible design/will cost too much to modify – refactor your design to focus flexibility on the variations inherent in your problem domain. Not everything needs to be flexible! * Domain irrelevance – Build only what is relevant to your domain. If you are not sure, [don’t commit](https://vijaynarayanan24.gitbook.io/art-of-software-reuse/process/delay-commitment) prematurely. * Ability to meet deadlines/dates (schedule risk) – cannot take a reusable asset to the planned design target? Plan to pursue refactoring these in your future iterations * Increased development, testing, and maintenance costs – don’t build domain irrelevant reusable assets. Every asset you build should be for a real business need. Refactor the rest so as to leverage existing solutions – watch your costs go way down. * Pursuit of technical elegance/architectural purity – again, refactor imperfections over time. Think incremental and iterative. I am not saying this will solve all your problems and address all the risks. But, it will get you on the right path. If you step back and focus on what is essential and what you know is likely to vary you can adjust your efforts accordingly. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vijaynarayanan24.gitbook.io/art-of-software-reuse/why-reuse-efforts-fail/risks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.