Part of Listed's 100 Day Writing Challenge.

Yesterday, I wrote about why I care about privacy in my blog post. Which kind of led me to think about today's topic for the blog post, 'Trade-off'. Gains to privacy usually results in more inconvenience, and inversely, more convenience tends to results in a degrade in privacy. Hence the 'trade-off'.

'Trade-off' exists everywhere, time spent on your work could have been time spent with friends. Money spent on luxury items could have been money spent on investment. Accepting one job offer means you might lose out on other job offers. 'Trade-off' exists in software development as well, which is what I will write about today.

It's Always a Trade-off

You see, in software development, every tech stack you implement, every architecture you design, every code function you write. All of them, they have a cost to them. The costs are usually accepted or prepared for. For instance, if you wanted to implement yet another bookstore website, the questions you would ask:

• What features shall be inside the website?
• What tech stack do I use?
• What is the system architecture like?

In those cases, as you begin to form your answer, some argument begins to appear in your mind, perhaps:

• This feature is too complicated to implement, is it worth my time to do it? Will customers even use it?
• But that other tech stack looks 'shinier' compare to the one I want to use.
• What if I need to scale the system? If I consider for future expansion am I making it too complicated? Do I really think my website will shoot off to a million users?

Your mind is usually processing trade-offs internally, arguing with itself. Ultimately, the decision you chose will be influenced by the following factors:

• The project specifications (client/customer requirements).
• Your own, opinionated mindset on how to solve the problem.
• Existing similar solutions out there (that you have seen).
• Curiosity/hype about some shiny new technology.
• Team member's opinions.

Now, I wanted to just write a blog post about this topic. The decision that you (or your team) has choose is unlikely to be 'wrong'. In fact, I believe that software design rarely has a 'wrong' in the first place. There is just the 'correct' decision, and the 'more correct' decision. The best decision you can make is the one you can proudly announce, welcome debates about, and still defend with confidence. A decision you are willing to stand by during a debate is probably the one with drawbacks you can accept and cons you are prepared for.