Learning Goal: I’m working on a writing discussion question and need a sample draft to help me learn.
Respond to at least two of your peers’ posts by Day 7. Your response should be at least 200 words.
1. Keyona
I believe YAGNI – “You Aren’t Gonna Need It” is essential. In my case, I tend to overthink everything and worry about every possible scenario and how I can improve or address an issue before it becomes a problem. My experience has shown that the fear of a thing tends to be bigger than the reality. Therefore, concerning oneself with something that is not an issue at the moment can result in wasted time and energy. This mentality is true in life experiences and software design.
Explain the rationale behind the practice you picked.
The YAGNI principle helps avoid overthinking possible situations that are not an issue now. Ingeno (2019) stated, “The problem with implementing a feature that you think might eventually be needed is that quite often the feature ends up not being needed or the requirements for it change” (pg. 182). Spending time on something that does not help solve a problem means losing valuable time and money on something that needs immediate attention. But this is not to be confused with creating software that is easy to manage or modify later. Ingeno (2019) explained that this principle is about functionality that is not currently needed. Focusing on the problem at hand adds more value to the project than providing a client with something they did not request, nor will they use.
Analyze your choice and how it will impact the overall quality of the software
YAGNI is a good principle for extreme programming (XP) practices. In this practice releases occur in very short cycles and is advantageous for organizations. The design should be a simple as possible and extra complexity is removed at discovery (Tutorialspoint, n.d.). It is easy to get caught up in all the hype associated with programming and enhancing the user’s experience with UI or the excitement of others telling the developer to do this or have it do that; while it is nice to have fancy features, it is not a requirement. In many cases, the features may get very little to no use at all. Ingeno (2019) mentioned that it is a violation of the Interface Segregation Principle (ISP) when classes are dependent on an interface with methods they don’t need ( pg.191). Instead, start with basic and primitive designs and then allow the software to evolve. Because there may or may not be a need for the fancy features, it is a question to be asked at the appropriate time in the process. GeeksforGeeks (2022) suggests that not adhering to YAGNI could be costly and a waste of time and utilizing this principle helps minimize complexity.
The goal is not to keep adding features but to consider whether the next level of sophistication is necessary now or later, thereby refraining from the desire to over-engineer a solution. There are situations where YAGNI does not apply. Ayana (2018) suggest YAGNI does not apply to code, making software easier to maintain and modify later (pg. 182). Using this principle does not indicate that developers should not look toward the future and consider future improvements, but to accept that everything will not get implemented at once. Nevertheless, creating software that allows for modification enables changes to occur easier when there is a need.
Conversely, there is always a chance of missing something that should have been addressed before hand, but the benefits of implementing YAGNI out ways the issues that could arise by ignoring this principle. While this principle is ideal for extreme programming (XP) it is applicable in all kinds of software development processing and methodologies (GeeksforGeeks, 2022)
2.Shantavius
Guidelines and practices can be used by software architects while creating software architectures, and they should urge developers to do the same. These guidelines and techniques are used to boost reusability, decrease maintenance complexity, and find flaws. In addition to ensuring that software engineering meets quality standards, reasonable testing procedures help direct and mold the actual development process (Ingeno, 2019).
The practice I feel is most important in my personal experience when applying the SOLID principles is the Liskov Substitution Principles (LSP). Liskov Substitution Principles states that subtypes must replace their base types without altering their base types, which is an object-oriented principle. Subtypes that inherit from a base class should be able to replace the base class without any problems (Ingeno, 2019). This pattern closely resembles my experience when programming a motor for a conveyor that delivers a product at different speeds depending on the sequence it calls for. In this case, the base type or parent class is the conveyor. The motor is a subclass or a child that contains characteristics and features that identify it, such as the motor speed setpoint, the min/max of speed setpoint, alarm features, and inputs and outputs. The Liskov principle applies when a series of events necessitates a conveyor to change speeds from high to low while only affecting the motor (sub-class), not the conveyor (sub-type).
The logic behind this practice is that “objects of a superclass should be replaceable with objects of its subclasses without breaking the application” (Janssen,2018). If the event sequence allows for the motor’s properties (sub-class) to be replaced with a conveyor (superclass). In theory, this should not fault out the program. To make sure that your code adheres to the Liskov Substitution Principle, you must put in place your own checks. Code reviews and test cases are the ideal tools for accomplishing this. To ensure that none of the objects used in your test cases introduces an error or materially alters the performance of your program, you can run a particular section of it with objects from every subclass.
Along with the Liskov Substitution Principle. The KISS principle minimizes complexity when applying the Liskov Substitution principle by inheriting accidental and essential difficulties, which are issues that software developers can resolve. Some of them may not even be associated with the issue they are attempting to address, and some issues that is a known problems but can’t simply be addressed due to the nature of the software (Ingeno, 2019). Using KISS is a design philosophy that specifies that systems and/or designs should be as straightforward as possible. A system should strive to be as simple as feasible since simplicity ensures the highest degree of user acceptability and interaction. (Ingeno, 2019).
