Asier's thoughts

Blogging about software development

Leave a comment

Giving estimates

Why do we estimate?

We, the delivery team, estimate so we can predict the time is going to take us to finish a task. It could be a new feature, a bug fix or whatever. This way business people can have a rough idea of how long is going to take to have a code change in place.

But this is just an estimation. Not a commitment. We can’t say it’s going to take us 3 days and then rate success or failure depending if we met that estimate or not.

We are humans and we are not good making predictions. We are optimistic. Even if we could predict exactly how long a task will take many things could happen in between that we weren’t expecting.

Making predictions for long projects it’s even worse. If we are bad estimating for small tasks imagine adding up all those deviations.. Estimating a whole project it’s wrong. And that’s why we have agile or things like #norprojects. Even #noestimates.

So what do we do?

First, we are aware. Estimates are going to be wrong. So we will tell the business that our estimates are just predictions and tell them we are giving just a guess.

They are going to be wrong specially in the long term. So we will give estimates to the business within a sprint, one week or two weeks should be the longest. If they ask for a feature that it’s not within the scope of the current sprint we will say “Sorry, I don’t know”. If somebody comes and ask “when do you think the project will be finished?” we will say “Sorry, we don’t know. I could give you a day to make you happy but that would be just lying and I don’t want to.”

So we will be honest. We will be professionals and don’t tell lies to our managers or business people just to make them happy for the time being. Managers want to know when things are going to be finished so they can put in place all their figures and budgets and all of that, but using estimates for that it’s just lying. Also if we are working in a feature and we find an impediment which is going to slow us down, we will say it as soon as possible.

We will build trust.

Leave a comment

Learning how to learn

I feel lucky to be a software developer. Things are changing rapidly around us these days. New languages, frameworks, libraries, methodologies, patterns are showing up every day. So quickly that it’s frightening, you have to keep learning all the time! I see this as an opportunity. An opportunity to learn how to learn and get better at it. Here some tricks I’ve been following:

First, failing is learning. So be aware of that. We learn from mistakes. The pain of a failure will make you not to repeat that mistake again, it’s the quickest way to learn. So fail fast. The faster you fail, the faster you will learn.

This reminds me a quote from Batman begins:

Bruce: I wanted to save Gotham. I failed.

Alfred: Why do we fall sir? So that we can learn to pick ourselves up.

But failing is not enough, you have to learn from reflection. Each time you fail observer the failure. Why did it happen? How can I avoid it next time? Don’t get attached to the feeling of failure – this is difficult.

This is not just for failures. Every day, every week, every year look into yourself. What have you achieved? What did you do wrong, what did you do right? Why? Think, observe yourself and learn from it. This is in-line with the great Eastern cultures like Buddhism where contemplation is a big thing.

You have to also explore. In order to learn new things you have to try new things. Obvious, right?  We all are used to doing the same things over and over again every day. We are lazy. We are afraid to fail when trying something new. But that’s silly. You should try to do new things, if not how would you discover them?

To make the best of this your have to get out of the comfort zone. Do things that you wouldn’t do normally because you would be afraid to fail. Failing is learning, so it’s okay if you fail. Explore as much as you can without the fear of failing. Do crazy things if you have to.

Embrace Kaizen philosophy and continuously improve. Always seek for perfection. Fail, reflect, learn and improve. Rinse and repeat. Every time getting a bit better. Be ambitious.

And the most importantly, make it fun. Learning should be fun, find that motivation.

As I said, being a software developer forces me to learn fast and get better at it. The thing is that this is a skill that you can apply not just to software, but to your life in general!