Sunday, May 21, 2017

Get your basics right with these smart software principles

A software is always written and rewritten to make it relevant for business and technology. It makes more sense not to violate some basic and important software principles. Languages and tools you use may provide some best practices and principles. But in general independent of what technology you use, some design principles are fundamental and adhering to it helps to ship quality and maintainable software.

I'm highlighting some important software principles below and few suggestions on how to enforce in your work and project.

Single Purpose: Each unit of code should serve one purpose and do it well. Unit of code can be a function, class etc. depending on the language you use.

High Cohesion: Keep related logic together in one place to have high cohesion. Depending on your project, it can be in your module/class/library

Loose Coupling: All components in the system should be loosely coupled for maintainability and easy modification

Side effects: Avoid side effects. This is a wide topic of discussion in functional programming, but in simple terms, it can be explained as side-effect is when an operation has an effect on a variable/object outside its intended usage.

Immutability: Don't mutate variables and objects wherever applicable.

Write Simple and Readable Code:  Coding is a collaborative work. Write code which is simple and easy to understand. Don't complicate things even if the language and tools you use support complication.

Wrong Abstractions:  Too much of abstraction is bad practice. There is no definite answer on what is the correct level of abstractions. But one best approach is don't prematurely abstract things and do when the need arises.

DRY /Avoid duplicates: Avoid duplication of code and logic wherever possible. It is fine to have some level of duplicate code when you are in initial phase of the product but it has to be resolved at right time. ( Refer technical debt below)

How to enforce it?

Below things, you can do in your project to enforce the best principles

Refactoring and Iterative development: Develop a culture in your team where refactoring and iterative development is encouraged as good practice. Especially it is far more important when you are in the initial phase of your product development.

Technical Debt: Maintain a list of all the technical debt in your project and iteratively reduce it.

API-Centric Model: API-centric model has many advantages. For instance, by reviewing API spec/contract, if you see if an API expects additional inputs than its intended purpose, you can easily figure out and avoid even before implementing the code.

Code Reviews: Do peer code reviews before you push the code . Especially review the unit tests/ test cases to catch any potential violation of principles.

Tools / Linters: You can use code linters /tools which enforce best practices in your code

Let me give you some casual examples to understand some of the principles.

Example 1: Suppose you are the developing a module in your application where it sends the notification to users through various channels like email,. API should get the details related to its intended purpose, say a recipient list, content, email subject, attachment. etc and send the notification. But if you also add more business logic not related to this module,  then it is a sign of bad practice.

Example 2: If you find a super function/class which does many things in your project, then it may be a sign of prematurely you are abstracting things

Project Management Musings - Polygot

Generally, the term polygot refers to programming and technologies where the ability of person work on multiple languages and technologies.  In the context of product and project management, it is someone possessing skills to contribute in other roles of the project apart from his/her primary responsibility and ownership

For instance,  below are the responsibilities and roles in a typical software development project.


Business Analysis, Product Management, Product Ideation, Product Development, Technical Architecture, QA


Tech Lead / Lead Developer,  QA Lead,  Business Analyst, Product Manager

The Core responsibility of a QA Lead is to plan the testing and ensure product quality is met. But if a QA Lead can contribute to Business Analysis, he/she can do the process of QA better and give a new perspective to product and business.

Similarly, a technical person can contribute to Product Management, Business Analysis and can make the technology and project deliverables close fit to business.

Depending on your product, you can combine the roles and responsibilities to get a new perspective on the product and also enable the team to do their primary role more efficiently.

Project Management Musings - Context Matters

Implement your processes and decision-making aligned with the context.  Context can be the current scenario and  factors surrounding the project

Some of the questions you need to ask yourself to understand the context.

Which phase of product lifecycle are you in?.
Are you working on a product already used by many customers?
Are you a startup trying to figure out the right market fit?
How is your team comprised of and what are their Strengths and weakness?
How far does your current funding go?
What is the current market trend related to your domain and product? .etc.

Suppose you are a startup and have a potential customer.

Do you resolve major issues in the product, unblock and release your initial version and get feedback?.  (or)  Would you adhere to all processes you planned before making release?.

You need to move fast, you may need to change your processes based on the context.

Always take your decision aligning with the context!