Software Flaws — The Big Three
When writing software, developers run into a pleathora of problems. There are an infinite amout of bugs and errors that a developer can run into but on a high level flaws exist in software that can be mainly broken down into three categories. These flaws all revolve around this idea of the law of change. The law of change states that the loner a program exists, the more probable that any piece of it will change, this is the idea that one has to keep changing the system so it can be helpful to users. More specifically the three flaws are as follows,
1. Writing code that isn’t needed
- This is the idea that adding too much code, or coding for a feature that will be implemented in the future is not good practice
- This also includes ideas of trying to handle every exception that could be thrown, or coding to handle weird inputs
- This flaw can be counteracted by good software design
- Only wrtie the code that is needed for the requirements of the project
2. Ridgid Design, not making the code easy to change
- This is the idea of designing in too many assumptions about the future, that is not identifying that the requirements of a project can and will change over time
- Antorher aspect of this flaw is wrtiting code with out enough design, the more you assume things wont change the more your code becomes spagetti
- A good rule to follow to aviod this flaw is that code should be designed based upon what you know now, not on hat you think will happen in the future
- Another good rule to follow is that the quality level of your design should be proportional to the lenth of future time in which your system will continue to help people
3. Over Engineering, being too generic
- This is the idea that one cannont accomidate every future requirent now, or simpler putting in too mch effort for too little value
- Another way of looking at this flaw is the idea of trying to be ‘smart’ by for example catching exceptions that don’t need to be caught, expecting input that you will never get, handling situations your system will never be in, or injecting deendencies when theres only once choice
- A good rule to follow to aviod this flaw is to be only as generic as you need to be right now
The idea of Incremental Development and Design can be utilized as a way to constatnly combat these software flaws. This includes things like rethinking your system/program design at every step, and having a notion of the order in which a elements of a project should be build.
