Back To Basics and Fallacy of Buzzwords & Trends on Software Development

For the past few months, I have been writing a thread of posts on LinkedIn under the title An opinionated guide to launching a harmonious career in software development.

The recent one on this thread talks about "Old vs. New" in software development.

Never ignore the old techniques, paradigms, principles, thought-processes, methodologies, libraries, frameworks, programming languages!

Upon reading this, one of the readers has asked a good question

This is true, all new popular tools and technologies are not right for the problem you solve. But how do you do make that call? When do you start switching to new and when you would fall back or stick to the old?

It's a good question!

I initially thought of answering it in the post itself and then realized it's a broader one and requires a long answer. Hence, I am writing this post to share my views on this.

Deep Understanding of Problem Domain

Before choosing a tool to aid in solving a problem, we need to have a deep understanding of the problem that we are solving.

Software is supposed to make life easier or better for the end customer. To do it effectively, we need to have a solid understanding of the software's business domain. We have to develop an interest in understanding the business and putting ourselves into the shoes of the human beings who will be using the software.

It's one of the underrated skills in software development. We as developers love creating things and our minds gravitate towards the solution always. If we marry this passion (or curiosity) with a deeper understanding of the business domain, we will be very effective in what we do.

Asking The Right Questions

Product Management & Development often suffer by XY Problem.

The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. - xyproblem.info

The client/stakeholder wants to solve the problem "X", and he/she has decided the feature "Y" is the solution for the problem. They talk to you to implement the feature "Y".

Now you as a developer have two options.

Option #1: Start developing the feature "Y" using the given specifications. 

Option #2: Probe the client/stakeholder on why they are proposing the feature "Y" and what is the real problem ("X") it is trying to solve. 

In a typical organizational setup, there will be a hierarchy between the developer and the customer. A business analyst or product owner will do the problem analysis and come up with requirement specifications. The developers get into the order-taking mode and blindly translates the specification into a working product.

Few organizations encourage developers to question the requirements. I firmly believe this is how software development should happen.

The developer who is building the system has more and broader visibility of the software product than anyone else. If he/she takes control over this, we can avoid unnecessary efforts and save plenty of money and time.

Coming back to the "XY Problem", if the developer has the power/liberty to probe the actual requirement (solving the problem "X"), he/she may come up with the feature "Z", which can be simpler to implement than the feature "Y". 

The developer has to know the "Why"s behind every code they are writing" and they should be encouraged to ask the right questions to know these "Why"s. 

When you develop a feature, always see the big picture and visualize how the people will be using it when it gets released. If you feel the requirements given to you don't align properly with the end-user, get back to the client, and have a conversation about it. You are not an order taker; you are also a stakeholder. Remember the technical skills is just one piece in the software development.

Code is not the goal

Programming is an art and skill of building a thing that solves a worthy problem. A given problem can be solved in multiple ways. The correctness of the solution is always with respect to the context of how we are looking at it. The solution is the manifestation of the programmer's thought process!

The code is not the goal.

Solving the problem is!

If an excel sheet solves the problem, I will happily suggest the same to my customer instead of building my own solution through programming :)

The Buzzwords Trap

The IT industry tends to focus on buzzwords and hot technologies. Most of the architectural (and design) decisions are heavily influenced by the current trends.

Don't fall into this trap! The business requirement should drive the decisions, not the buzzwords!

(Example Buzzwords: Microservices, Serverless, GraphQL, BlockChain, Kubernetes, NoSQL, ML, AI). I am not against any of these buzzwords. But my concerns are around using it blindly. )

As a programmer, your objective should be delivering the solution which satisfies the customer's requirement with minimal overheads during both development & maintenance.

If the given problem can be solved using a Monolith, don't try to solve it using a Microservice.

Learning a Technology/Tool/Library/etc

Whenever you are learning a new tech/tool/library/framework/language, don't just focus on learning the ins and outs to figure out how to get your job done using it.

Spend some quality amount of time learning and understanding the following

• Why the creator(s) created it in the first place?
• What made him/her/them to create this?
• What is the underlying thought process behind it?
• Where it draws inspiration from (any fascinating history)?
• What principles or thought-process it advocates?

Knowing all these will give you a broader picture and increase your knowledge portfolio to a greater extent.

Evaluating a Technology/Tool/Library/etc

Software Development is all about tradeoffs. There is no one size fits all solution. The context in which we are developing the software really matters. The best practice in one context would be a bad one in another context.

Whenever we use a tool/library/language/framework to develop software, inherently, we are giving up on something.

• What is the problem it is trying to solve and how much it resemble the problem that I have? Do I have really have that problem
• When should I not use it?
• Will it help me in delivering the software in the given context?
• What are all the tradeoffs if I use it?
• Will its Benefits outweighs the tradeoffs?
• How would my life be if I don't use it?
• What are we optimizing for?

Our primary responsibility as a software developer is to minimize accidental complexity as much as possible. We should not just make tech decisions without evaluating them against these parameters.

Invest In Your Knowledge Portfolio

Software Development is an open-ended problem. When we choose to develop software using a particular technology stack, we are just selecting one way.

Each programming language/libraries/frameworks/technology effectively solves a problem in a given context. Before learning or using it, we need to apply the "First Principle" thinking and understand it from the ground up instead of just using it.

To start with, get a good understanding of one tech stack and be prolific. Then gradually think outside of that tech stack and widen your knowledge.

Programming is Communication. Communicating to a computer on how to solve the problem and communicating to your future self (and your team members) on how you have solved it.

To communicate, We use the programming constructs and the idioms provided by the programming language. Then We use the abstractions (design principles & patterns) idiomatic to the programming language. While programming, our thought process is influenced by these things, and the resulting codebase reflects this.

To get better at this communication, we have to learn different programming paradigms that introduce us to new programming constructs and abstractions. This new way of thinking kindle different ways to communicate and makes us versatile.

Here is my recommendation for paradigms & best languages to learn these paradigms:

• Object-Oriented Programming - Ruby
• Functional Programming - Haskell
• LISP - Clojure
• Logic Programming - Prolog

You will see a better version of yourself after you learned "TO THINK" in these languages!!

Conclusion

In IT, the software product is the asset. The code we write, the tool/library/framework/tech we use to make the software are liabilities.

As a Software Developer, our primary responsibility is to minimize the liabilities and maximize the asset by making it more valuable to its end customers.

Most software product development is not inherently complex, but we make it complex because of how we approach its development. Following the latest trends and applying them blindly to build software is a million-dollar mistake!

Remember, the end customer doesn't care whether we are using serverless, microservices, blockchain!

All he/she cares about is, will it make my life easier and better?