When the target becomes an anchor

Target dates you are asked to hit can easily become anchors for your estimates. This could bias the way you think about the effort that will truly take to complete something.

If possible, try to come up with your estimates before a date is planted in your mind. If you know beforehand, try not to work backwards from that date because you'll increase the chances of biasing your estimates. Put the date aside, and estimate your work trying not to think about it.

Anchoring is a real threat to accurate estimation. The further away you get from it, the better the outcome will be.

An estimate is not a commitment

Just make sure everyone understands what your estimate means. You aren't committing to anything by telling someone how long you think something will take. You are just giving your best judgment about it.

One idea is to start giving your estimates as a range (from the most likely outcome to the worst case); ranges spark conversations most often than straight values. Another idea is to mention your estimate separate from your commitment: "I think it will take 2 days, so I can commit to have it in 3". A third idea is to just stall when you aren't ready to commit; ask for more time until you have an appropriate answer.

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.