HW16: Chapter 9
9.8 Three main types of software maintenance. Why is it hard to distinguish between them?
1 – Fault repairs to fix bugs and vulnerabilities. These have three kinds which in order from less serious to more serious are coding errors, design errors, and requirement errors which can involve significant system redesign.
2 – Environmental adaptation to adapt the software to new platforms and environments. These are the kind that are required when the environment such as the operating system or hardware changes like a major database upgrade.
3 – Functionality addition to add new features and to support new requirements. As mentioned in the first type, system requirements responding to organizational or business changes can require a lot more changes to the software depending on the scale.
There is no clear-cut distinction between these types of maintenance. Software faults can be the result of users using the system in unexpected ways in which case it would be better to change the system to accommodate their way of working. Different people also refer to these by different names such as corrective maintenance, adaptive maintenance, and perfective maintenance which further obfuscate the type of maintenance being performed.
9.10 I believe software engineers should develop code that can be easily maintained even if not required by the employer because at the end of the day if the code is being heavily used there will inevitably be requests for added functionality. Code developed for ease of maintenance and understanding will allow anyone to be able to update the code not just the original author and working in big teams that will be one skill that will allow you to work in better and more interesting projects and hand down your code to junior developers as case studies on how programs should be developed. Nothing is worse than being handed software that is poorly understood because of a lack of common architecture and no comments or documentation. It could take days or weeks to just understand the code enough to feel safe enough to make a few changes and be able to test. Ethically it is the right thing to do for the good of the employer and your colleagues to develop clean code.