Monat: Dezember 2009

Today was an oddly relaxing day at work. Tomorrow will be the last sprint demo of the year, and my team and I are pretty confident about the results.

However, it’s always a strange feeling you get so close before the finish line. You half expect something big to show up and show its nasty face, just like it happened last time – and that wasn’t a great experience.

But today I realized there are a few things you gotta learn to stay at least half relaxed through the whole Scrum thing. 

First, I’m sure that no matter how well everything is going, you always expect something big to happen at the very last minute. We had three bugs popping up in the last 48 hours and dealt differently with each of them:

• The first one was fixed by a developer yesterday evening and had unforeseen consequences. Basically, the original bug was fixed, but in its place a new bug appeared. Since the developer is on annual leave for the rest of the year, we decided to roll back the changes and get back to it in 2010. The original bug really was an edge case „only-happens-when-somebody-screws-with-security-settings-anyway“, so it seemed like the right call to get everything back to how it was before and tackle the problem with fresh energy.
• The second bug turned out to be an already known bug in slightly different clothes, so we could move it to a different team’s queue and just check it off our to-do-list.
• The third bug was brought to our attention by someone from another Scrum team and that one was also moved to the queue of bugs to fix in the new year. It actually was something left over from the sprint before this one. Plus, another developer on my team was smart enough to whip up a small test project and realized that it actually was a bug in the standard Silverlight control, and not in our code, so the solution might be to just file a bug report with the Silverlight guys.

What I’m trying to say is that the first thing I tried to find out about each problem is whether it would affect the sprint demo. In each of these cases the answer was „no“. Yes, some of these bugs need fixing, but none of them were critical and rather than letting panic reign the day before the demo, we decided to just keep our cool and assess the importance of each bug.

And yes, each bug fixed is a good thing. But sometimes, a bug hastily fixed in time for a demo is no good at all. We learned our lesson the hard way four weeks ago and we all agreed we would never make that mistake again.

So I’m still crossing my fingers and hope that we didn’t miss anything big. And I realized that I need to get used to the feeling to be afraid to have missed something. Apparently it doesn’t go away. However, if you learn how to deal with it, it’s not that bad. First, accept that this is how you feel if you care for what your team has done. Second, let go of the little things. There will always be bugs. But, if you’ve done a good job, there will be less.

Today we had an impromptu code review during a meeting which is actually intended for our feature teams to get together with the platform team to discuss any issues, ask questions or just address anything that might be of interest to others.

This time it was mostly our team trying to get some input on problems we already had discussed within our team but felt we could need more people to chime in on and collect new ideas.

My main issue was that I felt that I was stuck implementing the UI for a pretty straight forward feature. Unfortunately, though it was straight forward, it was also fairly non-standard. The good news was that we had implemented similar features already. The bad news was that we had implemented different parts of what I needed (or thought I needed) in different features, so I was taking code from three different features and trying to mesh it together for what I needed. I had come to a point where it was kind of working, but not really.

I had also come to a point where I didn’t know where to start looking to solve the issues I still had. Our team lead told me that she’d take a look at it with me to figure out where the problems were. That was pretty much what I was looking for, but since I was pretty frustrated already I went on a bit more about… well… basically about how frustrating it was that I was digging through code that I felt I should understand, but really didn’t. I guess my frustration showed, because the next thing I knew, I was asked to bring my laptop so we could all have a look at the code and figure out where the real issues were.

There were six of us and it took us about an hour to get through the main parts and leave me with a pretty good idea what was still missing and how to solve it. As it turned out the code wasn’t half as messy as I thought it was, but I had made a couple of stupid mistakes, mostly due to my inexperience with frontend development. We got to tidying up the code a bit and got the feature up and running (with a couple of things missing, but still).

At the end I wondered whether I should feel bad for taking up five developers‘ time to look at my code. But you know what: I think I shouldn’t. Both my team lead as well as another developer from my feature team said that they actually liked the small code review session and I got the impression that everyone else liked it as well.

Here are a couple of thought on why code reviews are good for everyone:

• Everyone looks at code differently. Everyone thinks differently, so you get a lot of new ideas you would have never though of.
• Everyone has different experiences, so it’s a simple way to learn new stuff. It’s also a good exercise for explaining things to others.
• You’ll see problems and issues popping up that you didn’t know where actually a problem. This also goes for pretty small and random problems that otherwise would have never been mentioned. So now you have a chance at solving them.

Basically, code reviews are a good way to solve an actual problem, but it also might reveal a couple of underlying problems that people weren’t aware of before. It’s a nice and communicative way to get your brain working, whether you’re more of an expert in the matter discussed and are suddenly forced to explain concepts to your colleagues or whether you’re the one with the questions trying to find a solution to the problem at hand.

If you’re someone who doesn’t like to present your messy code to others for fear of being thought of as stupid or if you’re someone who doesn’t like to throw ideas around the room while purely looking at code projected on the wall, code reviews might not be thing for you. For a code review to work you can neither try to hide your coding mistakes not can you point fingers and laugh. It can turn out to be a challenge for everyone, but it can be a pretty rewarding challenge at that.

I guess my main point is, if you feel like a code review could help, do it. If you’re the one with the problems, don’t be shy. Everyone makes mistakes, everyone has problems understanding different things. People understand. If you’re someone with more experience, share it. Explain. And for everyone involved I would just say: Ask. Help. Suggest. Try. Enjoy.