How to Make It or Why Less is More

Each minute and dollar are equal to the last. The one you will need might not have.?

Imagine yourself in a desert without water. What do you do? Are you going to start doing physical exercises? Will you go in the direction of a survival tools expo??

You get out of the situation with the least amount of time spent, ideally moving to the nearest safe place in a straight line. If you don’t do it, you have a solid chance of dying. This is the opportunity cost.

Any positive choice is actually always a mixed meal of one positive choice and many negative choices. You opt to do something in place of all the other things you could have done instead.

In software development, the two most important resources you spend to move forward are time and money. Do you want to spend your team’s time like in the left chart or like on the right one?

What is productive work? Well, all the things that ultimately, maybe not immediately, result in money earned. What if I tell you that for most teams it’s probably the case on the left, and it’s not even bad on average?

Companies and startups spend time and money they don’t have on things they don’t need in the foreseeable future.?

• Excessive code?
• Methodologies
• Tools they don’t need at the stage

One can argue that building in that DB engine flexibility ahead of time will make adapting a new database later. But what are you building? Is this some sort of B2B on-premises application you are actually planning to install in customers’ environments? Then yes, do it. But oftentimes, I see people doing this for the sake of “flexibility” or “extensibility” without any real plan to use any other database engine in the foreseeable future. And you know what? If this flexibility is possible at all, this is going to be an easy refactoring anyway, and, realistically speaking, some refactoring will be needed regardless. But! If you build the flexibility ahead of time, not only will you lose time on implementing it everywhere, but you will also lose time maintaining and testing it and will pay this “complexity” tax when working with the code base all along. “Code is a liability”

Or maybe that Continuous Delivery methodology can help you build quality in long before release. But, how about taking advantage of productivity, building things in parallel, and integrating them, say, 6 months ahead of the release, still long before production? Will there be a difference in quality? I doubt it. There will be differences in your business outcome though.

How about all the fancy tools? They absolutely might help and make your team more productive. It absolutely may be worth it. But will it be at this exact moment? You will spend time acquiring them and setting up them, mastering them, and maintaining them. Think twice about bringing in a new tool and make this investment decision wisely.?

And the last category is my favorite: things that will not work. I mean, do you really think that you can just pay a small amount of money and have a non-standard product built with world-class quality?

The beauty of backpacking - you have a travel plan in mind, which involves both the distance and time involved - the immediate scope. You reflect on what you really need and take this and only this with you. You are going to carry all you take on your back.

So what’s up with the charts? Only the work that can be compared to moving out of the desert as soon as you can in the most efficient way can really be considered productive.?

It should always be a constant reflection on what you are doing exactly and why the way it is done makes the most sense right now.