Writing Code vs Writing Software

“Writing Code vs Writing Software” Eh!! What does this mean? Well this comparison was brought forth during discussions with some of the developers. I was always under the impression that young developers these days are fully aware of the difference between writing code and writing software. I have to admit I was wrong!!!

Okay, now let’s understand writing code vs writing software. To explain, let me knit up a fictitious story of a character named Raj (no I am not a die-hard SRK fan, but loved his character name). 

Raj, studied computer science from one of the premier engineering institutes in India. He was amazing at hackathons, algorithm competitions etc. He used to solve puzzles and algorithmic problems very very quickly. He could code up the solutions in like minutes. He won many many accolades during his university years.

Now, Raj joined one of the most sought-after internet companies of the world. He cracked the interviews as he was accustomed to solving problems. He started with his first project, he hacked the shit out of his first project. Then he handed it over to one of the senior developers. Let’s call the Senior Developer Bob (I am sure this is the first time you would’ve heard this name ;)). Bob, started to give feedback to Raj. 

Bob started asking these fundamental questions:

• Is the code readable by a human?
• Is it maintainable?
• Can the code be easily extended when needs change?
• Is this code secure?
• Is the code doing too many things? Can it be broken down into smaller pieces?

Raj could answer none of the above question with an affirmative yes. 

Raj was however confused, why are these questions important. That is when Bob explained to him, writing software is an art. This art form is not restricted to one individual (mostly) but is usually accomplished by many developers. When the accomplishment needs to be shared, the guideline to achieve the same must be shared as well. The closest analogy I could think of is of plants ; All(Most of the) plants have roots. Similarly, writing software(plants) also has fundamental rules (roots). The rules are not relevant when you have to write code because the end goal is different there. While coding, we typically end up living up to the rules of the language we write code in. Anyways, enough of philosophical rant. Let’s get down to real meat!!

Bob started explaining with one of the most important principles of Software Programming: SOLID principles (mostly relevant in Object Oriented Programming). 

Raj realised that he wasn’t taught any of these principles at his university, however Bob calmly explained him.

(BTW, Bob gave other feedback as well, but for this write up lets stick to SOLID. 😉)

Bob explained, the above questions can be answered by applying SOLID principles.

Let’s understand SOLID.

History (Someof the details below are from the wikipedia article/s on SOLID)

"The theory of SOLID principles was introduced by Robert C. Martin in his 2000 paper Design Principles and Design Patterns, although the SOLID acronym was introduced later by Michael Feathers.”

Let’s unfold the acronym now.

(S) Single responsibility principle

A  class should have only a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.

This one is quite straightforward. We as humans are made to work on one thing at a time, don’t understand the reason why we tell other fellow humans multiple instructions(in the form of code) at a time.

(O) Open–closed principle

Software entities ... should be open for extension, but closed for modification. Why? The reason behind this is that every time a code modification happens, the risk of adding bugs increases.

Closed for Modification but:

• Can be modified only in case of fixing an error.
• To refactor in order to comply to SOLID principles

Open for Extension through (standard Object Oriented Techniques):

• A class inheriting parent class
• An interface containing method signatures
• Parent class having abstract methods

(L) Liskov substitution principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. 

It was introduced by Barbara Liskov in 1987. LSP is a particular definition of a subtyping relation, called (strong) behavioral subtyping. It is a semantic rather than merely syntactic relation. It has mathematical interpretation as well, however the simple explanation below should explain the meaning.

"if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.)"

In Object Oriented Paradigm, the following rule may help in visualising the concept:

Access modifiers, Exceptions or any Business rule/condition cannot be strengthened/weakened by the subtype.

(I) Interface segregation principle

Many client-specific interfaces are better than one general-purpose interface. 

If there is OCP, then we could end up in many interfaces, however, we must keep a principle here as well; No client should be forced to implement methods that they do not use.

A large interface should be split into meaningful interfaces such that clients know what interfaces are important for them and have no knowledge about methods that they don’t need.

(D) Dependency inversion principle

One should "depend upon abstractions, [not] concretions.

Higher level modules should depend on low level modules, both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Now, Dependency Inversion is one of the most important principle which must be adhered to. In fact, in my experience I have seen decent applications being developed by just conforming to this principle. Multiple programming languages have frameworks supporting Dependency Inversion. One of the most prominent one being Spring in Java.

Okay now back to the story.

After so much explanation, finally Raj understood the importance of working on this art (building software) like a craftsman. 

Raj was able to find a mentor who knew how differentiate between writing code and writing a software. Not everyone in Indian IT ecosystem can find a mentor like Bob. Indian IT ecosystem is basically IT Services ecosystem(86$ billion services vs 7.1$ billion software products) wherein the importance is given to make the system work. This isn't wrong. However, when we start writing software (aka software products) which can lead to revenues (or operational efficiencies in case of in house softwares) we always falter as we keep the believing, the end goal is to make the software work. Sustainability of software development is never an important aspect.

P.S -> This write up is in no offence to people who focus on learning to write code (algorithms, data structures etc.) rather its focus is to make people aware that there is more to writing code in order to create a software. And the skill needs refinement when people from engineering colleges/universities start mainstream professional work.

Until next time!! Stay tuned.