Functional wisdom for software engineers

The beginning is the most important part of the work. - PLATO

Motivation✨✨

The average article intended for a software engineer fails to impart one key element to the readers - "Inference" or "Deduction".

Let's take a Key-Value store for example 🔥. Initial search gives us definitions, advantages-disadvantages and some interview design tutorials. All these articles provide sometimes rich but shallow information that might be relevant to perform well in an interview but leave us in an inconsistent state🤷🏻‍♂️🤷🏻‍♀️.

The process of building a software project has been sparsely communicated and for the most part stayed hidden in the software engineering community🏴‍☠️🏴‍☠️.

The creators of these articles and videos consistently ignore to mention their deductions and just present the results like a scientific study📖📖. They fail to impart the wisdom to come up with such ideas, make assumptions, document them, implement and test them, discuss the cases when the above assumptions could be wrong, and re-iterate the whole process again.

This blog is my attempt to bridge this gap🔧🔧.

My personal framework💪🏻💪🏻

This is the framework i use while working on a project. These steps will be common across all kinds of software engineering roles.

1. Coming up with an idea🤔🤔.
2. Gathering the requirements🕵🏻‍♀️🕵🏻‍♂️.
3. Making appropriate assumptions😅😅.
4. Creating a high level design & low level design👨🏻‍💻👩🏻‍💻.
5. Take feedback from peers👏🏻👏🏻
6. Implementing the code🤠🤠.
7. Testing the implementation🤮🤮.
8. Verifying assumptions and coming up with anti-assumptions✅❌.
9. Iterating all over again🔃🔃🔃🔃.

Types of software design

There are majorly 2 ways in which a software could be designed.

1. Top-down ⬇️⬇️
2. Bottom-up ⬆️⬆️

In the Top-down approach we start with a somewhat concrete set of requirements, number of users, API model and some other relevant assumptions. We then start building the High level design and Low level design to match the requirements. This method ensures that we are not drifting off an actual goal as the requirements are almost fixed and works great in a corporate environment🏦🏦.

In the Bottom-up approach we start from the absolute basic level of the problem we try to solve. We then take try to find bottle-necks which may occur when we throw more users and more work. We then tweak our initial design or sometimes completely re-do it and arrive at a point where we repeat the steps all over again📷📷.

The risk of diminishing returns

80% of effects come from 20% of causes and 80% of results come from 20% of effort.

Every software has its limits, there is no perfect software that fits all needs. At some point in following the above framework a question arises: When should we stop?

When the rewards are too low from the effort that needs to be put in. I simply call it the "Effort-Reward" ratio. If it is in the favour of new improvements then you should go ahead with the changes else think twice before investing your time in improving the software.
With this I leave you readers with the anticipation of the next post in my blog.

✌🏻
Peace.