If you do a quick Google search for how to get better at estimating software tasks, you'll find multiple people recommending the way they do it. Some of these recommendations are some variation of the following ideas:

3-point estimates

It's being a long time since I estimated something using a single value. Providing a range is usually a better practice, and forces a different thought process that's extremely valuable.

One hundred 1-hour tasks or one 100-hour task

Are these the same really? I know that mathematically they are, but do they represent an equivalent effort for your product?

Estimates vs. Process

Where would you rather invest your time? Upfront to try and come up with a more accurate estimate, or throughout the project to manage around an inaccurate estimate?


"Prioritization" as in having a conversation regarding all the tasks assigned to the team and coming up with the best plan to achieve our goals.


There are three people in the room helping you out with an estimate. You discuss the next feature, then ask for everyone's opinion. A guy and a girl think it will be two days. The other guy thinks it will be five.


One of the biggest changes from moving to a management position after being a developer is getting used to having other people do what you've been doing your entire life.

Engineering values

Having values is something crucial, not only for your social life but also at work, to guide everything you do.

Advancement opportunities

From our "Engineering handbook", here are several areas that you can focus on to make sure you achieve success:

How to measure the performance of your developers?

For years companies have tried to measure developers using all sort of hard metrics, like the number of lines of code they typed, or the bugs they fixed, or the bugs they introduced, or how early they finished. It doesn't matter how you try to slice it, every one of these metrics can (and will) be manipulated, which makes them useless.

Getting a project back on track

Here are some specific notes to keep in mind to help a software project get back on track. Some of there might not apply to you, but take a look and see if there's something that helps you get things where you want them to be.

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.

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.

The best and worst case scenario

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

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.


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

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!"

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.

The more you have, the more you should protect it

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.

Statecharts and wireframes

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


Some people don't always like to 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.

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.

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.

Thoughts about OCL - The Object Constraint Language

Right now I'm taking the Software Architecture and Design class (CS6310) for my graduate degree. Specifically for the last couple of weeks, we have been looking into OCL (Object Constraint Language).

Don't do functional teams

There are multiple ways to organize a development team. You need to take into account your business and the type of work you are doing. Every company is different so is every manager.