SOLID principles for Object Oriented Programming, with LIQUID and GAS

In Object oriented programming, the SOLID principles play an important role in designing the solutions and structuring the code.

For a quick recap, below is what SOLID briefly stand for:

• S - Single-responsiblity principle: A class should have one job, and only one job.

• O - Open-closed principle: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

• L - Liskov substitution principle: Every subclass / derived class should be substitutable for their ancestor classes

• I - Interface segregation principle: No client should be forced to depend on methods it does not use.

• D - Dependency Inversion Principle:1) High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). 2) Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions

But solid also happens to be a state of matter. To make matters fun, here are 2 more acronyms that can be used in software development, to complete the three commonly found earthly states of matter :)

LIQUID

• L - Learnability: The program/module/class/method should support enhanced learnability of anyone using / extending it
• I - Input validation: All inputs must be validated to avoid any security and other bugs
• Q - Quality control: Code should be structured so that ways to keep checks on regression and maintain strict quality can be easily ensured. i.e., tech debt should be kept within viable limits
• U - Understandability: Code is modified and debugged more number of times than freshly written, and it must thus be easily understandable for the next person. Conventions needs to be followed consistently
• I - Integration: Code in isolation is limited in the impact it can have, and so must be so structured to promote easier integration within other projects / modules etc.
• D - Defect averse: defects have a way of creeping in, so code should be properly tested and structured in a way to minimise code smell and defects.

GAS

• G - Great readability: Code is read a lot more than it is written, and to save time, should be readable.
• A - Avoid Anti-Patterns: While using design patterns and other strategies is good, one must know when to avoid the common anti patterns
• S - Security promoting: Unsafe security practices should be avoided at the offset. As Mad eye moody says, Constant Vigilance is the way to avoid security nightmares.

Waterfall vs Lean vs Agile vs Scrum vs Kanban

If you work in software development, chances are, you've heard of all the terms above.

Over the years, all of these terms have turned into buzzwords, with people using them witout even understanding what they really stand for. So, its common to hear things like waterfall is bad, or asking that a scrum team adjust their changes for newer requirements, or use kanban boards to keep track of stories.

In this post, let's have a look at what all these terms stand for.

Waterfall:

This represents a unidirectional flow of development process, where various steps are taken one after the other, in order. So, first goal is to do requirement collection, next an analysis of those requirements, followed by designing of solution, which is finally coded, implemented and integrated, to be released to the customer.

Waterfall works great when the requirements are static. That is, they are the same on the day of delivery, as given on day of initiation. However, most business requirements and projects are not static. Each of the steps above take time by themselves. Businesses are today much more dynamic, and even the customers are lot more demanding. Which is why, taking feedback becomes a necessity, and this is what is the achilles' heel of waterfall model is.

Lean:

So people looked into other domains to find out what stands out in other industries to make the process more efficient, and the final product less defective. One existing mecahnism they found was the Six Sigma and Lean management.

Six Sigma is a disciplined, statistical, data-driven approach for continuous improvement and eliminating defects in a product. The six sigma method was inspired by happenings at Motorola. Soon, within the larger industry, most notably Japanese carmakers, lean management starting taking hold. Lean management stood for eliminating waste, and this principle got adopted to the software industry. (Just like how design patterns were originally inspired from construction industry, or how biology inspires many genetic algorithms).


Agile:

However, lean also did not fulfill all the aspirations. For, technology is ever changing, and in the technology world, the tools, the requirements, the customers, and the product, all change very quickly, as compared to other industries. So, the existing strategies started feeling heavy, with all the business requirement documents, technical requirement documents, technical specification, change management document, and a lot of other processes.

Many lightweight software development frameworks starting coming up to the fore, to counter such heavyweight methods, as, one size does not fit all. The result was an umbrella of methods, like Scrum, Extreme programming etc. Even later, newer methods such as Behavior Driven Development, Test Driven Development, Kanban etc kept coming up.

Agile gained popularity as this umbrella above, with the coming up of the Agile Manifesto.

Scrum:

Scrum is one of the agile methods. Scrum is a software development framework. By that, it means that Scrum provides a designated structure in which a Scrum team must function - it provides the roles (product owner, scrum master, scrum team), the meetings, and even what interactions should happen between the different members.

Today, scrum has come up as one of the popular agile framework for software development, with its focus on incremental delivery and constant iterations to deliver a requirement every spring end

Kanban:

Kanban is a lean management tool that got picked up from the car maker Toyota. Kanban is used to achive JIT (Just In Time), and the focus of Kanban is to keep Work in Progress (WIP) to the minimum. It is very useful in projects where the work can be heavliy broken down into equal sized tasks. However, many do not consider it to be a complete software development method.

The ORID technique for Focused Conversations and Learning

Reading upon some resources for better scrum setups, I came across an acronym - ORID - for managing retrospectives better.

The general problem with retrospectives is that people keep jumping to conclusions, or keep repeating the same things in different words.

But even during meetings involving larger number of people, such as postmortems, reflections, Root cause triaging etc, conversations degrade in quality, and at times, people fail to arrive even at the common interpretations of the same set of events. Thus, objectivity takes a hit, and it is hard to arrive at good action items that everyone will agree to. 

Things keep dragging on, until the initial momentum slows down, and is finally lost by cherry picking the top few low hanging fruits that work for everyone.

So, what is a good way to keep the discussion focussed, when people want to have good learnings from a common events and decide on what to do based on them?

One answer is ORID. In this post, I will explain the understanding I built from reading around various sources, and thinking back on situations I've observed.

ORID stands for 4 steps in questioning the shared event:

• Objective
• Reflective
• Interpretive
• Decision

ORID is driven by a facilitator experienced in the method, such that the participants may not even feel like the conversation is structured. It is a group exercise, in which everyone together forms the cohesive unit, hence also being useful in scrum which is naturally about one team. A lot of the output of ORID depends on how the facilitator structures the questions and modulates the discussions. Being a 4 step process that requires carrying context, ORID requires uninterrupted time, which can be a constraint in different setups.

In the first Stage, Objective, the group tries to remember the event and sequence of events that happened. From these, the facts are distilled, which all can agree upon to be facts. The facilitator has to keep an eye out for the discussion spiraling out of the objective into emotional territory - that is a later stage. The facts are stated and heaped together, but no analysis happens. So effectively, people tell what they heard, saw, know, read etc, but not what they feet, think, imagine, worry, doubt etc.

In the second Stage, Reflective, the emotions are dealt with. How do people feel about the topics - these can be positive, negative, apprehensive, or mix of other emotions. The focus here is to get the gut reactions of individual members, which may or may not be supported by facts of the first step. The idea is to get all the fears and concerns out in the open.

In the third stage, Interpretive, the focus is on the larger stakeholders/actors. By now, all people are aware of various facts about the events, and about the way others feel about them. So more or less, everyone has an idea of what others think. However, the focus is not the individuals, but taking a broader perspective. For example, What does this mean for the organization? for the business unit? for the individual teams? for classes of people involved (leadership, developers etc)? This step is all about analytical phase, but seen from the Point of view of different hats, and not an individual

In the fourth and the last stage, Decision, the group decides. The idea is to to think about the future, get concrete action items, so that they can actually be put into practise. The focus can vary from the practically achievable to the best course of action, given the resources.