I can’t imagine how my life would be if I hadn’t met him, but I’m sure it would be quite different. I would be probably working with different technologies and different groups of people. He taught me Erlang when I was a student, and through the years inspired me to take on many projects around its beautiful community. During my very first days as a professional he encouraged me to travel and meet prominent developers and scientists around the globe. He inspired me to love computer science and innovation. He gave me the chance of pursuing projects during years and see how eventually some of them flourish as new industrial technologies. He co-authored scientific papers with me. He trusted a young, inexperienced developer like I was on so many challenging projects that I was forced to continuously learn and improve just to pay that trust back.

He was such a relevant person on so many people’s life that the void he leaves after his untimely departure is so big that his friends, colleagues, and in general our software community will feel the effects for years. I hope we all can live up to his expectations and make him proud of his heritage.

I should have written about him long ago, he deserved to read it.

Víctor, I’ll miss you. Thanks for being such a good friend.

The tip of the deadline is obvious for everyone. And because it’s much more tangible than the invisible part, we usually try to do our best to get the work done in time. However, to do that we could be forced to implement dirty solutions and temporary hacks that will cost us time in the future. This effect is what I’m calling the submerged part of the deadline.

The effects of the submerged part are independent of whether we meet or fail the deadline. They are also independent of whether taking the short-cut paid off or was actually an unneeded mess. In either case, we are trading (wisely or unwisely) development time in the future for a short speed-up to avoid failing the deadline. If we do this often, after a year we would’ve wasted many weeks fixing stuff instead of implementing worthy functionality. This waste of time relates very indirectly to its cause, the deadline, which deceives us into a kind of sweet death without even noticing it.

So before the usual question “How can we meet this deadline?” we should start thinking “can we spare this deadline?” Each deadline we avoid is an opportunity for better planing and coding. However, deciding to spare a deadline isn’t easy. You, and the rest of the team, are seeing the tip! And you certainly want to avoid it. In order to effectively choose the right option we must work on implicit assumptions that could not be true.

Let’s try with an example:

We’ve detected a bug in our system that hits now and then each day rendering the system useless. Our sysadmins are mitigating it rebooting the systems periodically, but that creates short outages and users lose their sessions. Our customers are angry, we need a solution by Monday.

Our first reaction will be start running now, now, now! … but before we can try to make sure that is the best decision investing a few minutes discussing things like

• Whether Monday is really a hard deadline. Maybe it means “as soon as possible”
• Whether we really have any chance or having it done for Monday anyway
• Whether this failure is what is annoying the customers. Maybe they haven’t noticed thanks our sysadmins’s partial fix and are other problems what are disturbing them
• And could be more …

Blindingly trying to meet any deadline that could show up is a good way to weaken our competitiveness in the future, but it is very difficult to decide not trying to meet a deadline beforehand if we don’t take their long-term effects into account.