The best and worst case scenario

Some people like to talk about the best case scenario to complete their projects. Some people instead like the opposite, and they always refer to the worst case.

I think there's a better way.

The likelihood of a best case scenario happening is usually very low. You are calling it "best case" on the first place because you know something could (probably will) happen. So you make sure to label it as "best case" to properly set expectations and let people know that it won't likely happen.

If it won't happen, why do you talk about it?

The worst case scenario happens when multiple things go wrong at the same time. The interesting thing here is that, when too many things don't happen the way they should it becomes really hard to determine how they will impact the timeline, thus the worst case scenario is usually a fictitious date far enough in the future to put everyone's mind at ease. Perfect storms could happen, but our plans for them will likely be insufficient.

Again, if it won't happen, why do you talk about it?

Giving best and worst case scenarios is a simple way to dodge the real solution to the problem: a realistic plan that accounts for risks and dependencies, and covers multiple possible situations and their outcome.

Coming up with this realistic plan is hard. You can't just hide behind a date far enough in the future, nor behind the unlikely perfect picture. You have to think hard enough about the work, dependencies, and risks, connecting all of these and determining their impact and how to mitigate them.

Whenever you've done your job you'll feel confident standing behind your plan. Whenever you haven't, you'll probably try to masquerade it behind unrealistic expectations.

Protecting clients from themselves

I've always thought that is my responsibility to protect clients from themselves. If not specifically mine as an engineer, then it's definitively my team's job to help them achieve their goals.

Clients are rarely experts at software development; that's exactly why they come to us in the first place. Sometimes we forget the extent of our responsibilities and let them hurt themselves when making uninformed decisions.

Imagine you are working within a budget of 40 hours. If you chase after every single idea the client puts on the table, and end up spending the whole budget while working on superficial things, you can't just go back and blame the client for it.

Think about it: you are supposed to be on the driver's seat. You are supposed to provide support helping the client make the right decisions and tradeoffs. You are here to inform, help to understand, and provide alternatives. Is not about you shutting down every idea coming from clients, but about helping them understand the implications of implementing those ideas.

Looking at everything you do as your own offers an invaluable perspective that will help you make the right decisions. Every time I'm not sure what to do I like to force myself into thinking what would I do if I were the owner. All of the sudden answers become clearer than ever.


Today my company announced that I'll be filling the position of Director of Engineering.

At Levatas, I've always worked with very talented people, so I'm not just honored but extremely blessed for having a great team trusting me with such an important role.

It's a huge responsibility and I'll have to fill pretty big shoes, but I'm excited and can't wait to pour all the passion I've always had for this company into my new job.

Sometimes is not just about more time

Of course, the difference between finishing a 4-hour task early or being late is usually about time. "If I can only get another extra hour, I'll wrap it up for sure!"

Time is an integral part of software development (and pretty much everything else), but sometimes we use it a little bit too much to cover for our lack of understanding about processes governing our projects.

When a 6-month project finishes 3 months late, we can't just blame it on the calendar. It's the easy answer to the problem, I'm sure, but it isn't the real cause for why the project got extended 50% over the original timeline. Time is just the low hanging fruit that everyone loves to use to answer the hard questions.

In the long run, more time is not a solution by itself, but a consequence of needing to execute a different process, or to add another person to the team, or to revamp creative work, or to focus more on quality, or to spend more on upfront design. Whatever it is, that's what you need to find out; that's the real exercise we need to go through to make sure we properly fix the problem.

I'm voting for America

I'm not going to tell you for whom I will vote for on 2016. But maybe you can infer that from this post.

(Sorry for all of you who read my blog for pure technical reasons. This is not about software, but 100% about politics. You're free to skip if you desire.)

I was born in Cuba and endured 28 years of socialism. I did not come to this country just for "economic reasons" like a lot of my fellow countryman did; I came because I believe America is the best country in the world. I wanted to live in a place that fights for the rights of human beings and doesn't push personal agendas or ambitions over the well-being of its citizens. I wanted a place ruled by a common sense economical system and not the equalitarian chimera that has doomed my island for over 5 decades.

So I'm sure you will excuse me if I don't support a government that tries to bring me back to what I want to keep in the past. Today I'm an American citizen, and my vote in 2016 will not help chip away the liberty after which I uprooted my whole life.

I'm an immigrant who came here with pretty much the same as most immigrants: nada. But I didn't just ask the government for money, or free health, or started a fraud ring, or sold drugs. I started working immediately and have been making a decent living for the past 7 years. This country received me with open arms, and I want the same for everyone in the world as long as they come to do honest work and stop living off the rest.

I don't believe in government interfering with businesses in any way or enabling people to rely on welfare. I don't believe in a minimum wage and think free health and education are just nice ideas on paper but completely unreasonable and unachievable (unless you are willing to completely destroy both).

I believe in free speech. Free speech as the way it's meant in the Constitution and not the modern version that some have been trying to create. People should be able to express whatever they want, not whatever "it's appropriate" for them to say.

I believe in the Second Amendment. I'm grateful to be able to protect my family and my home. I'm also grateful to have an answer for anyone trying to do what a dictatorship regime has done in Cuba.

I came here because socialism destroyed my former country. I wanted to live guided by those principles that made this country great and I'd hate for a crooked president to keep destroying everything I came looking for.

But although you can call me "latino" or "Cuban-American", in 2016 I'm voting as another American. I'm looking out for this country, my well-being and my children. I want them to grow with the same rights I've fought really hard to get, and I really don't care who you think I'm supposed to vote for, because I'm voting for America.

The more you have, the more you should protect it

People care more about things they don't have enough of.

If you have tons and tons of money, you probably spend it less carefully than somebody who lives paycheck to paycheck. Water is more valued in California than in Florida where it rains all the time. Scarcity makes everyone think twice.

The same happens in software projects.

Teams usually get up in arms near the end, when budget is running out and deadlines are rapidily approaching. When both money and time are scarce, everyone starts thinking about them, and bend over backwards to fix the problem.

I think we can do better.

Precisely, it is at the beginning of the project where teams waste more; right when budgets are big enough and deadlines not yet in the horizon. Every decision seems inconsequential so nobody cares.

But this quickly catches up with the team. And just when everything should be coming together for a landing to successfully close the project, is when more and more pressure everyone feels from every angle.

The more you have, the harder you should work to avoid wasting it. You need to start looking at consequences right from the get go, not just when things get tight.

Statecharts and wireframes

I've always relied on wireframes to communicate the user interface requirements of a system. This is definitively a very good approach that helps everyone understand how an application is supposed to work.

It also has shortcomings; sometimes it's hard to communicate specific details without putting together wireframes showing all the different possibilities.

The process gets expensive really quick. The amount of time needed to put together these wireframes is definitively high compared to the time needed to use a statechart for the same purpose.

Here is a quick and high level statechart representing how this blog works as of today:

Obviously, with a statechart I'm limited to communicate behavior and not styles, or layout. It's a very good approach to tell the story of the interface of the system, however I feel it's very underused in the Industry.

Wireframes are still a more sexy way to solve the same problem. But they're also more expensive, slow to create, hard to maintain, and sometimes, difficult to decode. They generate a lot of waste when used incorrectly.

Statecharts are one possible answer to that.


Some people don't like to constantly jump from project to project. Sometimes I don't either. I guess you get tired of switching context; of having to learn everything again without the satisfaction of resting on past accomplishments.

Focusing on one project, or one type of project, or one vertical, or anything predictable and constant offers the opportunity of specialization, and that's a great thing. You definitively don't need to jump like crazy, but you also get the benefit of becoming really good at it.

That's a great thing, for sure.

But the same could also become boring. Even worse, it could lead to stagnation which could easily destroy a good team really quick.

Going from "cutting edge, awesome team" to "old, stuck in the past" doesn't take that long in the software world. Things change too fast for us to get too stuck in old ways, so anything that offers an outlet to try, improve, test, fail, start again is a blessing.

Remember this: your sharpest, more awesome engineers will never put up with the same project for too long. They understand they need to move on, to learn new things, to improve.

Preparing for the future

Even the more detailed and well-thought plan to finish your project can go awry at the very first turn. At that point is when all of us realize how bad we are at predicting the future, send a rant to our boss by email, and demand clients to stop asking questions we can't answer.

Yeah, I've been there myself. And unfortunatelly clients don't care and they keep asking things that I don't know today. Why in the world would they care about how long until we finish? Or how much are they going to have to pay us to get everything done?

Can they just trust me?

No they won't and they shouldn't have to.

Making a release plan is not about predicting the future, but about setting well-informed expectations with the client. We all understand that things may go wrong and render our plan invalid, so a good process will have to cover for this appropriately.

Here are a couple of things you want to keep in mind:

  1. Do not think of a release plan as something you set and forget. Keep in mind that every single decision you make has a direct implication on your release plan, which makes it a live, constantly updating plan instead of something you email the client on day 1 and then never bring up again.

  2. The key to control changes on your plan is constant communication with your client. Have them walk the walk with you so you can help each other make the right decisions for the project.

  3. Finally, a good release plan calls obstacles before they happen, plans to mitigate them, and proposes solutions for when nothing else can be done. Assuming everything will always go as expected is irresponsible and unrealistic.

You still won't be able to see the future, but you'll be using your present and past to better prepare for it.

Estimation is not about accuracy

Here is one thing I know about estimation in software development: It's not only hard, but it's also not about how accurate you can get.

Hey listen, I understand that the more time you spend in the Industry, the more experience will help you out coming up with estimates to develop features for a software application. That's clear, but that still will not make you a wizard that's able to see the future.

I've been related to software for more than 20 years, and foreseeing how long certain things will take is still as painful as day one. Sure, I'm probably doing better today, but I'm also still wrong most of the time.

But you know what? It doesn't matter.

If you put together all your estimates to develop a software product (and assuming you have enough experience to provide decent estimates), you can easily represent them in a bell curve: most of them will be pretty accurate, but you'll also have several outliers, both under and over the target.

From here on out is all about properly playing your cards: every time you come under, don't waste the remaining time; use it instead to offset those instances where you invariably came over. Whenever you are over, make sure you properly adjust deadlines and priorities. Communicate with your team and have them walk the journey with you.

There's no book out there, or course, or professor that can teach you how to get more accurate with your estimates for a good reason: you just can't change the fact that predicting is hard. But remember that it really doesn't matter. It's all the about the process, not the number itself.