Software Development and Engineering Blog


HW28: Chapter 25

Sam Word | 21 Nov 2017

HW27: Chapter 24

Sam Word | 16 Nov 2017

HW19: Team Progress II

Sam Word | 14 Nov 2017

HW25: Chapter 23

Sam Word | 09 Nov 2017

HW24: Chapter 22

Sam Word | 06 Nov 2017

HW22: Chapter 21

Sam Word | 02 Nov 2017

HW19: Team Progress I

Sam Word | 31 Oct 2017

HW21: Chapter 20

Sam Word | 26 Oct 2017

HW20: Chapter 19

Sam Word | 24 Oct 2017

HW18: Chapter 18

Sam Word | 18 Oct 2017

HW17-B: Chapter 17

Sam Word | 11 Oct 2017

HW17-A: Chapter 16

Sam Word | 08 Oct 2017

HW16: Chapter 9

Sam Word | 05 Oct 2017

HW15: Chapter 15

Sam Word | 02 Oct 2017

HW14: Testing Reflections

Sam Word | 28 Sep 2017

HW13: Chapter 8

Sam Word | 28 Sep 2017

HW12: Mythical Man Month

Sam Word | 26 Sep 2017

HW11: Chapter 6

Sam Word | 21 Sep 2017

HW10: Chapter 5

Sam Word | 13 Sep 2017

HW9: Reflections

Sam Word | 12 Sep 2017

HW8: Chapter 2

Sam Word | 12 Sep 2017

HW7: Reflections

Sam Word | 07 Sep 2017

HW6: Chapter 4

Sam Word | 07 Sep 2017

HW5: Reflections

Sam Word | 05 Sep 2017

HW4: Chapters 11 & 12

Sam Word | 30 Aug 2017

HW3: Chapter 10

Sam Word | 28 Aug 2017

HW2: Responses

Sam Word | 27 Aug 2017

HW1: Chapter 1

Sam Word | 24 Aug 2017

HW0: Introduction

Sam Word | 23 Aug 2017

HW15: Chapter 15


02 Oct 2017

15.10

The reuse of software raises a number of copyright and intellectual property issues. If a customer pays the software contractor to develop a system, who has the right to reuse the developed code? Does the software contractor have the right to use that code as a basis for a generic component? What payment mechanisms might be used to reimburse providers of reusable components? Discuss these issues and other ethical issues associated with the reuse of software.

To me, the simplest solution to determining who has the right to reuse developed is to let the developer decide who can reuse the code they developed. Each time we sign up for a new account on a website, every time we install a new application, and nearly any time we use any service, we agree to a set of rules for using that software or service, often called the Terms of Service or a Licensing Agreement. If the developers of the software want other developers to be able to reuse and edit their code, such as the developer of Linux, then they can specify that in their terms of use. If the developers want their software to not be reused by anyone outside of their team or company, or not even to be run on any hardware, such as Apple’s OS X, then they can specify that in their terms of use. Any number of rules and conditions can, and should, be specified by the developers of a software system.

Not every software system should be open to external extension and reuse, especially to outside developers, regardless of how much time and money could be saved. Of course, the original team of developers should at least revisit previous conceptual solutions to a system before creating a new system to solve the same problems, even if they plan on rewriting them instead of reusing them. However, not all code should be open to just any outside developers. For example, banking apps. Wells Fargo is free to reuse their own software at their discretion for a new banking app, but security issues could arise if their apps were open-source. Therefore, I believe they should have tighter control over who can reuse their mobile banking app software. Additionally, not all software should be reused without considering implications of reusing that software. The Therac-25 radiation therapy machine reused software from a previous model, but its creators didn’t consider possibility of the old software failing, and decided to forgo installing hardware safety checks. Because of this, I believe that software reuse should save time and money on development costs, but not in testing costs. Since behavior can change when a software system, or a portion of a system is reused, the new system needs to be analyzed and tested as thoroughly as an entirely new system.