Trade-offs

Trade-offs

Every programmer has been faced with that moment when they had to say “I’ll do this part later.” But honestly, how many times did we really do it later? And when did “later” come? 

The first reason for resorting to this excuse is rather unfortunate. We’re masters of procrastination and of putting off things that are less important than the feature we’re working on at the moment. There are many tiny parts of the process that need to be done, but frankly, they can be quite boring. And this is where many programmers use that lovely phrase “I’ll do this part later.”

To be fair, there are moments when we don’t have any other option. There are only so many hours in the day, and we can’t be in two places at once. That is why we have to choose what to do and what to postpone. Imagine programming like a constant To-do list that doesn’t get smaller; on the contrary. When an app or a website is being developed, creators or clients have only a vague idea of what they want. No matter how many documents you write, no matter how many meetings you have, there will always be something you missed. The more complex the project, the more things pop up later.

And that’s when trade-offs kick in. A trade-off usually means choosing one thing over something else. There are two types of trade-offs: the real ones where you have to choose to do either one task or another (e.g. we can either have fast calculations, or we can request fewer processors and spend less money) and then there are the fake ones when you just try to avoid the tedious part of the work (e.g. doing the separate page would be too much work, so we just patch this page up. No one will notice a thing, right?). The second type is not a real trade-off, it’s just an excuse. And it happens for various reasons, starting with a simple “I don’t feel like doing it” and ending with a “deadline was so close that we just needed something presentable, no matter how bad it was”.

Unfortunately, the second reason is the most frequent in programming. Clients and managers often take their time in the beginning of the process, and then they have to fight a deadline. And it’s the programmers who are caught between a rock and a hard place. Then the whole process can be summed up as time vs. quality because some clients don’t realise that there is such a thing as a scope triangle. It contains quality, speed, and price. You can get two out of three apexes, but never all three. You can have quality work in a short time, but it will cost you money. Or you can have cheap work done in a short time, but it won’t be any good. And you can have a quality inexpensive work, but don’t expect it any time soon. As a result, often programmers have to forgo the quality of their work to meet a crazy deadline.

Of course, deadlines are a nightmare for any programmers, especially if these are set by clients or managers. More often than not, the set deadlines are based on a feeling rather than on real work that needs to be done. And frankly, who can predict – I mean really predict – how much work will be needed? Most programmers tend to overestimate the amount of work needed; while clients and managers do just the opposite. On top of that, clients and managers sometimes don’t realise that you can, say, either have a near unhackable system, or you can deliver a hackable system on time. Of course, this doesn’t have to be a problem. For example, imagine you play a computer game, and you need some in-game material to make progress in the game. If no validation on how you acquired said material is in place, some players may use this weakness to their advantage, but the worst that can happen is that they will get to the next level faster. I’m really glad that Pixel Federation is serious about validation, so don’t even try this in our games. If you have no validation of a transaction on your internet banking account, anyone can send money online from your bank account, and—I probably don’t have to continue here. 

Real trade-offs are really one or the other, but fake ones are repairable with time and/or money. These fake trade-offs – or in a layman’s term “I’ll do this part later” programming – should be rectified as soon as possible, especially if security is in jeopardy. No one wants broken code. Unfortunately, fake trade-offs are an unavoidable part of programming, mostly due to lack of time. Every programmer just has to make sure that a particular trade-off brings the desired results and no disaster. And if possible, the “later” should really come some day. After all, you never know when something you wanted to do “later” will come back and bite you in your—