Software Evolution - HW11

HW11
9.8 What are the strategic options for legacy system evolution? When would you normally replace all or part of a system rather than continue maintenance of the software?
The strategic options are as follows:
1. Scrap the system completely Only used when there is no longer a reliance on the system.
2. Leave the system unchanged and continue with regular maintenance Chosen when the system is generally stable and requires only general maintenance.
3. Re-engineer the system to improve its maintainability Chosen when the introduction of new features lessens the system quality, needed to help facilitate the integration of new and old systems.
4. Replace all or part of the system with a new system Chosen when continued operation of the old system is not possible due to the introduction of new hardware or software.

An entire replacement of the system is obviously a huge re-factor, and requires careful decision making. Normally it would only be done under specific circumstances such as the introduction of new hardware that the old system will not run properly on. If the system cannot continue to operate normally then a full or partial replacement is necessary.

9.10 Do software engineers have a professional responsibility to produce code that can be maintained and changed even if this is not explicitly requested by their employer. 
This comes down to personal belief and ability to self-motivate. As I've said before, it's easy to just write code and not worry about anything else. As a professional there is an unspoken rule that your code should be reliable, maintainable and easy to read. I believe that software engineers absolutely have a professional responsibility. Outside of school you will not have much explicitly requested of you. (Side note: I feel that some classes spoon feed us too much, we often receive explicit step-by-step instructions on a homework or project. We should move away from this in order to motivate self-instruction and good project habits.) It's likely that you'll only be asked to complete a task and provided with a few specifications. It should be unspoken and understood that you will complete that task to the best of your abilities, which means writing good code.