YAGNI (You aren't gonna need it)

For this blog, I chose techtarget’s blog. The definitions are kept simple, concise and easy to understand. YAGNI ( You aren’t gonna need it or You ain’t gonna need it ) is a practice in extreme programming associated with software development which states that features should only be added when required. Most developers including myself have included code that is believed will be needed in the future to perform a specific cool task. It could be a feature collects the user's age so we can determine which age-group is mostly using a piece of software. However, YAGNI teaches against this, developers don’t have to waste time writing source code that is assumed will be needed in future. The extra wasted effort is unnecessary and can hinder or slow the development process.
 
Features are expensive, both to develop and maintain, and for users to learn and navigate around. This could result into delays that may give competitive advantage to rivals.  Features that aren't necessary at the time of production are a huge waste. YAGNI can be compared to the Just-In-Time manufacturing where rather than ordering a bunch of parts based on what you think you might need, you wait for actual customer orders and ensure your process is lean enough that you can pull orders through your supply chain quickly enough to satisfy the customer.
 
On the other side, it may be necessary to think about future features and fashion current features in a way that integration will be seamless. This does not mean shipping those features in the current release.
By avoiding adding features and complexity until it's needed, the overall design of the system can remain simpler and makes it easy for debugging as well. The feature you thought you would need usually turns out that you either didn't need it, or that when you do need it, your understanding of how best to design it will be different than earlier imagined in the project.
 
The YAGNI concept helps avoid spending time on features that won’t actually be used. For instance, in developing a calculator app, the system doesn’t need access to the user’s contacts, location data, or reading emails and showing adverts. These are unnecessary features that make the user interaction with the application undesirable. Most users will simply not use a calculator application that requests for their contacts, location, or bluetooth connection. This renders the application unusable and therefore dead.

Design Smells

I chose alpharithms blog to get definitions as they were well defined and short. After the English and alpharithms' definitions, I add a small example of how the concept are applied in software development. These are classifications of poorly written code making it hard to understand, maintain or modify. They include Rigidity, Fragility, Immobility, Viscosity, Needless complexity, Needless Repetition and Opacity.

Rigidity means to not easily bend. In software that means the code cannot adapt or be open for changes occurring around it. An example, we have an authentication module in our app. Later on we decide to determine the user's online status and display it to other users. This could be a challenge especially if we don't have parameters in the module that capture the exact time the user was authenticated and when they went offline.

Fragility means easily broken or damaged. In software this means a piece of code is delicate such that any slight modification to it could lead to breaking changes elsewhere including areas that have no direct relationship with the change. The programmer is locked between leaving it as it is which could potentially expose the system to vulnerabilities or remove it completely leaving other components broken because they depend on it.

Immobility means unable to move. In software, this means we cannot export this code to other parts of the system. There could be several reasons for that, including being platform specific or requiring a particular version of dependency to be met.

Viscosity, a term associated with flow of liquids. In software development it means the code cannot flow to other parts of the system and often it’s hard to do the right thing when faced with different situations.

Needless complexity. This is an easy trap to fall into especially when copy and pasting code that performs “cool” operation. Let’s say you’re developing a note taking app, you shouldn't need access to user’s GPS location, phone call records, and text messages.

Needless repetition. Instead of repeating source code, we could create shareable components and state management stores that hold data centrally such that it can be availed to other components without rewriting the source code. Repetition sometimes leads to inconsistencies in data especially if the components do not effectively communicate and update each other.

Opacity which means hard to see through. This means the code has arrived at a point where it's hard to understand what's going on due to several modifications. Let's say we build a calculate application that adds two numbers, next we add on computing the logarithms, then we add on computing the squares of multiple numbers. It just keeps on evoving until no one fully understands how to make modificaitons to the code.

Object Oriented Programming

For this week I chose 'The story of object-oriented programming", by medium.com. The blog dives right into the topic by stating that any developer who wants to build a high quality software out to master object-oriented programming concept. I learnt that object-orientation was intended to be closer to the real world and also making it easier. Objects in the real world, could be anything such as a house, car, bike, books etc. Objects have attributes and behaviors, that's how we identify them. Attributes are the properties of a particular object. For instance some attributes of the human race are having a nose, having eyes, having legs and so much more. Behaviors on the other hand are actions that the object performs. It could be displaying a message that is useful to the user, sending and delivering an email when a button is pressed, playing certain theme songs when new levels are reached in a game. Objects do not generate themselves, they come from classes througha process known as instantiation. A class is the home or blueprint where attributes and behaviors live. When an object is made out of a class, it is safe to say that it contains the exact content of that parent class.

In relevance to Software development, there exists four expressions to object oriented programming (OOP) namely, Abstraction, Encapsulation, Polymorphism and Inheritance. Abstraction means hiding the implementation details of a particular class. Basically, data and information that is irrelevant to the user is not presented to him/her.  A commonly used example is  about cars and their technical functionality such as burning oil in the combustion engine. As the car executes its source code, the driver does not need to know what events are happening under the hood in full detail.

Encapsulation means having an another object within another object. Sticking to the car metaphor, we can see the idea of encapsulation in car seats or tires. They (seats or tires) could be of different colors, material and from various manufacturers as long as they meet requirements of a particular car. Combined together, they serve the purpose of a car as whole unit.

From the word 'Poly' meaning 'many', Polymorphism is the ability of an object to be inherited by multiple classes. With polymorphism, it's easier to have consistency in data because child cases are reflecting data that comes from parent classes. Errors and inconsitencies are reduced.

Inheritance is the ability to share attributes with other classes. We do not need to repeat source code to execute a particular task. With inheritance, we can generate other classes that have the same properties and behaviors. For instance, a student and a professor both inherit their properties from the class human. They both have physical attributes and behaviors such as speaking, reading and moving.