Estimates Meetings

There’s a meeting that (I think) happens every week, where projects/enhancements are discussed and estimated. I don’t think there is enough time to really discuss them in great detail, and the people in the meeting don’t really care because they won’t actually be developing and testing them.

The thing is, it’s quite hard to judge how long something will take even when you have a decent understanding of the requirements, because you don’t know what the current state of the codebase is until you really start to dig into it. Also, you will uncover multiple problems and come across things you never considered earlier.

I think the key thing to remember is that ‘estimates’ aren’t supposed to be exact and are only based on the knowledge you currently have, plus additional time for contingency.

Even considering that, I think most people struggle to come up with estimates – even people that are regulars to the meeting and should be experienced at it.

One day, I received a message from my manager asking me to join one of these meetings. The meeting had been going for 10 minutes or so.

I join the call, and my manager tells the Host to re-explain. I felt awkward, he probably had done a great 10 minute explanation, and then they somehow decided they need my advice. So the Host reexplains. I ask a few questions, in particular about some previous functionality that had apparently been rolled back. I wanted to know why it was rolled back rather than fixed, because that would be key in coming up with an estimate.

My manager decides that we need the previous Product Owner on the call. She joins the call, and my manager asks the Host to re-explain. This is definitely awkward now. You can tell the Host is so frustrated, and he audibly sighs before explaining for the third time.

Now the group should estimate collectively, but everyone seems to want me to estimate it by myself. Why does everyone think this is a hard one to estimate? I end up being vague and saying it was 1-3 weeks. The thing is, they usually want the estimates to the nearest 2 week period, so 4 weeks is a fine estimate. I try to push the others to suggest their own estimates. The group decides it is too hard to estimate so the Host needs to come to a future meeting with more information. He must be fuming.

I get invited to next week’s meeting. There’s 2 projects to estimate – this time brought by a different product manager. This new Host says the first project was estimated a year ago, then put on hold. It was given 16 Weeks at a “high confidence”, however, there’s no notes to explain how they came up with that figure. But it is “high confidence”, so unless we know of any complications that have happened over the year, maybe we could stick with that?

Judging by the small amount of notes and screenshot, it looked like a few day’s work to me. One person says there’s some “cross-account functionality which is against the current architecture”. So now we are all scared. One manager states: “There’s too many unknowns, so let’s come back to it”.

So the Host moves onto the next project. It’s quite complicated and requires a good 10 minutes of explanation. When she got near the end, I thought “I hope we don’t estimate it; it will be a right laugh.” When she concludes her amazing speech, we decide “we need to break it down – it’s too big”.

So that’s 2 hours of meetings to estimate 3 projects and we didn’t estimate any of them. Good work team!

A Day In The Life Of A Software Developer #1

At the start of the year, I thought of a new blog idea. I could pick certain days to give a run-down of the day’s work, including some banter. I drafted this up before the lock-down when we were working in the office. I hoped to write a few blogs in the series before posting them, but that didn’t work out. I suppose I could still write some based on working from home, but there won’t be as much banter to write about. So here it is. Note, this was when I was in a team doing a Web-based project:

I get into the office and give my previous day’s work a quick test before I send a Code Review to my team. I load up the website, open the menu… the menu is screwed up and won’t open at all.

I couldn’t understand what happened. I’m sure this was working yesterday. I spent some time analysing my changes; I really can’t see how this has happened.

The Junior Developer gets in and I ask him if he can give me any ideas on how this can happen. “Oh, I saw this happen yesterday.“

“What? You saw it, and never said anything? You didn’t log it, or even post it on Slack for the team to see?“

“No, it is a minor issue“.

I was outraged. I’ve told him not to ignore issues. We are paid to make things work. Also, if it was logged, I wouldn’t have wasted time analysing my changes when the bug isn’t even caused by my changes. If a bug is logged, if someone assigns it to themselves, then you know not to waste time looking at it, because it is being investigated. If the issue isn’t logged, you can end up with 2 team members looking into it because they think it’s a newly discovered problem.

We end up finding the cause, and we correct it.

Someone talks about a Pop music concert involving the groups: A1, Five, Damage and 911. “Sounds like a traffic report“, Seth says. We all laugh.

It’s time for the Scrum Of Scrums. Dean is currently occupying the meeting room on his own, but on a conference call. Helen waits outside and debates with a nearby colleague if she should kick him out of the room. Josh says “maybe Dean is waiting for the Scrum of Scrums?“. Helen says it wasn’t the case. Dean sees them awkwardly queuing outside, so he quickly leaves the room. The rest of the participants for the meeting show up. A minute later, Dean comes running back exclaiming “I should be in the meeting!“. I laugh at him.

A colleague tells me about a massive rant on Slack about the poor communication from management. I read it. It is brutal, but they make a good point. The upper management have kept quiet, when they used to hype up projects all the time. Additionally, new staff members have been quietly hired, some have even quietly left. We used to get emails to welcome the new starters, and also got emails to arrange leaving parties for departing staff.

Shortly after, some guy I have never seen before is asking a manager, Tim, about the progress of some important bug fixes. When he leaves, another manager asks “who the hell was that?” Tim replies “he has been here for 5 months, he is the latest Project Manager”.

Well, that certainly validates the Slack rant about the quiet hirings. No one in my team knew who he was either.

I’m happy with my work, so I send a Code Review to my team. I check to see if there’s any outstanding Code Reviews that I can review. Last week, I had left a comment about lack of test coverage. The developer hasn’t bothered adding any more tests. I ask him about it, he seems to be playing dumb. I told him I would sort it. So that is tomorrow’s work sorted.

First job – The “just Google it” seniors

When you are learning programming, I think it does help to have some kind of mentor, or alternatively – many mentors. There’s certain aspects that are hard to learn yourself.

One simple example for me: Even though I could go out of my way to learn keyboard shortcuts, or find cool features of Visual Studio, I feel I have learnt the most by sitting next to someone while they work, or if they come over to help me. When they have the keyboard, they will bring up features I have never seen before, or manage to find files way faster than I could, and I’d be like “WOW! How did you do that?”. It’s amazing how much faster I am now, and it is mainly due to what I have learned from others.

When I started my first programming job, it was for a very small company (less than 10 staff), and I expected the Senior developers to help me a lot. Instead, when I asked them for help, they always said “just Google it”.

No matter how much I tried to argue with them that it would be faster for them to tell me, they would insist that I should Google it. If they were really busy, then fair enough, but I knew they didn’t have much work.

Sometimes you can find your answer fairly quickly by Googling. However, you still need to understand what you are reading, and sometimes it is far easier having someone explain it to you. It’s possible for someone to explain something in a few minutes, rather than reading a huge article for 20 minutes.

Also, you may not find your answer in the first article. You could have to trawl through several articles. Additionally, the articles could have a lot of irrelevant aspects to it that doesn’t apply to your situation, or confuse you further… possibly causing you to Google other terms you have seen on that article. You could end up with an hour passing by and you are left more confused than when you started.

Alternatively, maybe you find the correct answer, but the example code is in a different programming language.

Google only really works if you use the correct terms. If you know you have a problem but struggle to explain it, you don’t have much chance with Google, but an experienced human may be able to tell you the correct terms and concepts. At least a colleague has a good chance of understanding the problem you are trying to solve because they may have seen the requirements.

I vaguely remember spending ages trying to learn Threading, and I chose to use a “Thread” class. Then days later, when I had it working, I demoed it to the Seniors. They then said “why didn’t you use the Timer class, it is much easier?”

My thoughts were “why didn’t you tell me to use it when you knew exactly what I was working on, and knew I wanted some guidance?”.

It’s like they took great pleasure into watching Juniors struggle. They did mention that previous employees in my position left within 3 months, and they actually sounded quite proud of it. I always respect people that are smart and are willing to pass on their knowledge. It’s frustrating when you meet people that are smart but are so arrogant and patronising about it.