Padding

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:

  • Come up with your estimate and then multiply this number by 2 (or 3, or even 4!)
  • Come up with your estimate and increase the unit of time you used. For example, if you came up with 2 days, your final estimate should be 2 weeks. If you came up with 4 weeks, your final estimate should be 4 months, and so on.

The principle behind these techniques (and any of their variations) is to add padding to the estimate to cover for unknowns. Despite well intentioned, doing this doesn't really make you better at estimation. It doesn't make your estimates more accurate either, and there's probably an argument about whether this is even ethical.

Would your client understand and agree with the way you are deciding how long things will take? If you feel the need to hide from your customer the way you come up with estimates, then you probably have more work to do on this front.

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.

What I do is to think about three different values: the optimistic case, the most likely case, and a pessimistic case. I'll talk about PERT in the future, but for now, let's keep the idea as simple as possible.

In order to build that feature, it will approximately take 5 days if I'm lucky. Most likely will take me 7 days, but depending on this and that, it could take as long as 12 days.

Thinking about the optimistic and pessimistic scenarios in addition to your most likely case forces you to answer very important questions:

  • What happens if I end up not needing that difficult integration after all?
  • Am I considering the dependencies to finish this task?
  • What are the risks that could get in my way?
  • What happens if some of the assumptions that I'm making don't pan out as planned?
  • Am I sure that documentation will be clear enough to finish the work?

Considering the impact of different factors on your estimate is extremely valuable, and I've found that it rarely happens when you think about a single value. But even when you think about all of this, it is hard to represent the results within a single number. 3-point estimates will tell the story that you need your audience understanding: big gaps between estimates will immediately point out to risks, dependencies, and unknowns that we should clear up to reduce uncertainty.

From this point, you can use your 3 values in different ways:

  • Provide a range using the optimistic and pesimistic values (5 - 12 on the example above).
  • Provide a range using the most likely and pesimistic values (7 - 12 on the example above).
  • Get a little bit more fancy, and compute the expected duration using the formula explained here. (This would be my recommendation, but it is also more time-consuming, so I'll discuss more about it in a future post.)

At the end, even if you are forced to use a single value as your estimate, the exercise of coming up with 3 different cases will play a huge role in making your estimate as accurate as possible.

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?

Most of the time they don't.

On one hand, having multiple low-complexity tasks is good to keep a large team busy. You will usually find ways to parallelize the work by having different people work on different tasks at the same time. There's no reason you can't do this with only one big task, but the former is usually simpler.

Smaller estimates will also tend to be more accurate than bigger estimates, where there's a lot of hidden complexity that we can't understand until we get close enough to the work.

On the flip side, one hundred tasks are just too many opportunities to make a mistake, to harbor scope creep, to have too many balls in the air at the same time. More moving things represent more complexity.

Make sure you consider everything at play before you let math play tricks with your estimates.

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?

In other words, what would you prefer? A good estimate paired with a flawed project management process or a poor estimate together with a robust process?

Coming up with good estimates is something that we all should work to get better, but we need to make peace with the fact that there's no such thing as "a perfect estimate," and the only solution to an imperfect estimate is a strong process to manage projects.

That's what I'd do: invest as much as possible into building a strong project management foundation that helps navigate our imperfect estimates. This formula will certainly win every time.

Prioritization

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

After we know what we need to be working on, there are too many times when we pick up something completely random and focus on it. Some people do it by the size of the task; some people take whatever is at the top of their list; some others can't even tell what method they use.

There's a better way; before anything else, you should set up a strategy to tackle your list. The plan will always vary, but it will certainly run laps around the lack of one.

Here are some different questions that you can ask when determining the order of your list:

  1. Is there anything that could potentially change the direction we are going?
  2. Do we need early feedback about anything?
  3. Is there anything that we can quickly complete and forget about it?
  4. Is there a way we can organize the work to maximize the skills of our team?
  5. Is there anything that excites us more than everything else?
  6. Is there anything that will unblock another task?
  7. Is there anything that will unblock another team member?
  8. Is there anything that will facilitate our work on something else?
  9. Is there anything that will increase our confidence going forward?
  10. Is there a way we can organize the work to increase the collective ownership of the project?

Prioritizing work is like solving a puzzle; the order in which you put new pieces down matters a lot.

Averages

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.

Alright, then (2 + 2 + 5) / 3 = 3 days. You average the estimates out, write down the result and move on. As easy as that.

Except that's an awful idea.

Averaging estimates is even worse than picking the lowest or the highest estimate. When taking a side, at least you are giving credit to someone, but by using the average, you are forsaking and distorting everyone's opinion.

What should you do? Start a discussion. Ask why it should take five days. Ask why it could be as easy as two days. Find out what's making different people give different estimates. The conversation will likely float hidden requirements or misunderstandings about the work. That's what you need to happen before moving on.

Guilt-free

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.

Understanding that you are moving away from doing the work into a leadership role within the team is a big adjustment that came for me with a substantial ration of guilt; not only I started feeling like I was always dumping tasks on other people, but it was hard to feel participant on their victories.

Whenever my team did something remarkable, I felt it was all them. I felt jealous I wasn't part of it and struggled to value my contribution. I was "delegating" tasks after all, and they were doing the hard work, right?

Fortunately, I've learned to give credit to my job as well. It turns out that what I do is important after all! If you are in a management position, your actions will have a profound impact on your team, and their success will be closely related to your ability to guide them.

Think about everything you do for your staff every day, and you'll see there's a direct line connecting your job with their ability to do great things. Even things that appear trivial or disconnected at first will certainly provide support and contribute to your victories.

Today I celebrate with them. I've learned to respect and value my work, which has given me the strength to do it better. Now free of guilt.

Engineering values

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

Values are a little bit aspirational, but they are critical to understanding what's important, to guide the decisions we make every day, and to help us grow and create the future we want to develop.

Last week we shared with our team our Engineering Values. They took some time in the making, but I think it was worth it. Hopefully, they will give us a guide to keep growing our team.

Here they are, all ten of them:

  1. A great Software Engineer is passionate about software development. Great engineers have a passion for coding beyond anything else. They are passionate about helping shape the future of the Industry. They are experts in their craft and use it to push the boundaries of what they know.

  2. A great Software Engineer is humble and self-motivated to learn. Great engineers understand the importance of growing their skills. They are willing to leverage existing solutions, listen to others, and keep challenging the status quo to make things better every single day.

  3. A great Software Engineer pursues technical excellence. Great engineers continually try to get better at what they do and the way they do it. They never stop or get complacent. They are their biggest critic and strive to elevate the quality of every facet of their work.

  4. A great Software Engineer share experiences. Great engineers understand the real value of sharing experiences with their peers. They constantly look for ways to make the team around them look better by finding areas where others struggle and supporting them.

  5. A great Software Engineer runs towards problems, not away from them. Great engineers aren't afraid of failure. They look forward to solving difficult challenges as soon as they arise. They never back away from problems, and instead find a way to put themselves right at the front line.

  6. A great Software Engineer has a strong commitment to meet deadlines. Great engineers understand the importance of meeting deadlines. They make sure deadlines are both achievable and understood by the entire team. They help those around them get across the finish line if necessary.

  7. A great Software Engineer upholds a clear standard of quality. Great engineers take a lot of pride on the quality of their work and aren't willing to compromise it under any circumstance. They know how to manage competing priorities to deliver the best possible solution within the imposed constraints.

  8. A great Software Engineer has a "get stuff done" mentality. Great engineers are eager to build things, and they don’t stop until they finish them. They understand the importance of results over the process to achieve them, and while there's value on the latter, they value more the former.

  9. A great Software Engineer criticizes ideas, not people. Great engineers criticize ideas on merit alone and never the people who hold them. They believe that ideas should stand or fall on their own merits.

  10. A great Software Engineer constantly looks for ways to make Levatas a better workplace. Great engineers love their workplace and work together to make it a little bit better for everyone to enjoy. They understand that everything around them exists because somebody made it happen, so they respect it and improve upon it.

Advancement opportunities

I'm sure you've asked the question before.

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

  1. Increase your technical competence. Find ways to increase your value to your company by improving your technical skills. From picking up an entirely new language to familiarize yourself with a different section of your project, you should have plenty of room to grow and stretch your abilities. Look at those areas within the technology stack used by your company that most interest you and go for them.

  2. Improve your professional communication. Communication is usually overlooked by engineers when growing their careers. However, it's probably the single most important area we all can improve that quickly pays off. From flawless writing skills to understanding how to communicate with non-technical people effectively, there's a lot to cover that will quickly increase your value to your company.

  3. Improve your problem analysis skills. We solve problems every day. Large or small, every project needs people to come up with solutions that keep the company in the forefront of the industry. Get on the action! Try to improve the way you tackle problems. Ask the reason behind decisions made by other people, and soon you'll be able to contribute your own.

  4. Actively add value and take initiative. This is probably the simplest thing you can start doing right away. Don't wait until somebody tells you what to do. Look, and you'll see how every single thing around you is ripe for disruption, from making your project a little bit better to your workspace more enjoyable.

  5. Become the "go-to person". There's hardly anything else that will get you more attention than becoming the "go-to person" for your projects. Start by focusing on an area that's difficult or annoying and become an expert. Never lose sight of the quality of your work, don't over do it, and be ready to take responsibility when things don't go your way.

How to measure the performance of your developers?

Most of the time, there's only one correct answer: by the value they deliver.

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.

Developers produce intellectual property. They don't have an algorithmic job where you can easily predict the path and outputs given a set of inputs. This makes it very hard to measure their job, so you need to step back and look at the big picture.

(How do you measure the performance of a musician that's writing a song, or a painter working on a mural, or a novel writer? In all these cases the only thing that matters is the final result.)

So the key is defining what "value" means for your project, and make sure whatever it is; it gradually tends to increase. (Scrum teams use "velocity" for this, in which case you add all your individuals into one single number to measure their performance.)