Blame versus Bullshit

In one of our sprints I had worked with another developer to fix a bug that we found in one of the modules already implemented and integrated into the Main codeline. The bug must have been there from the start and it accidentally deleted an attachment from the database if it was considered too big to be handled by the UI. It was fairly easy to miss, although not exactly a minor bug. You just had to stumble over it at some point and we did.

During the sprint demo we mentioned this bug while going through the list of important bugs we fixed and it quickly turned into an argument with another developer from a different sprint team about whether this really was happening (it was, data was deleted from the database, we CHECKED), whether it had any side effects (it did, only those were the same side effects that had already been there from the start) and when this bug was introduced (guess what, nobody cared, it was a bug, it was fixed, end of story). The quote that stood out though was the overly awesome „Then it was not my code.“

So here’s the thing. Nobody cared. So far nobody had blamed anyone. Nobody had checked source control to see who was to blame, because so far nobody had thought about checking. Once we had found the reason why data was deleted we started working on a solution to not let that happen. Then we closed the case.

Naturally after the sprint demo the first thing to do was to actually check who introduced the bug. I don’t need to tell you, who it was, do I? On the plus side, from that day „Not my code“ became one of the most quoted lines in our office.

Here’s the thing. In our development department there was a lot of healthy blame going round. By healthy blame I mean the kind of blame where you find something wrong or strange in the code and you go to the person who wrote it and ask about it. It’s the blame where when a feature goes wrong you go and have a talk about why it happened. It’s the kind of blame where when you find awkward code you sit down with the developer who wrote it and go through the code.

To sum it up: You might name names, you find the responsible person, you point out the error. But you do it because you want to improve the team, the code and the process. This is not about telling someone that they are stupid or pointing fingers and feeling superior. The fact was, everybody was doing it all the time.

Yes, even this kind of healthy blame might feel bad sometime. It’s not your favorite moment of the day when someone stands at your desk telling you that you probably did something wrong. It’s also not your favorite moment when you have to go to someone and point out a bug that you found.

Here’s the thing: It’s not personal. It made people aware of when they didn’t understand a concept. You would sit together and figure out what the issue was and how it could be solved. It made you re-evaluate how you went about implementing something and probably made you vow not to do it again. 

Basically, healthy blame can be relabeled as „learn from your mistakes“. The only thing is that in order to learn from your mistakes someone actually has to come up to you and tell you. Otherwise it simply won’t happen. So embrace the blame. And as the blamer be prepared to be proven wrong. It happens all the time as well. That piece of weird code might actually have a reason – it just needs better comments.

What this has to do with „not my code“ is very simple. In an environment where blame is not considered evil, you don’t care about who did what and when. If it’s something serious or discussion-worthy you will seek out the person responsible. If it’s nothing serious, and easily-missed bug, some inconsistency or some code lines that aren’t exactly pretty, you just fix it, be done with it and move on the next thing. And that’s what we did.

A Very Very White Christmas

This might be the first white Christmas I have ever had. We got an unusual amount of snow for the last two or three weeks this year. Especially unusual for this area. I can’t help but enjoy it.

The last three months have been busy and eventful, which is one of the reasons (but a particularly good one) why a) it has been pretty quiet on this blog and b) our Christmas plans pretty much boil down to NOT GETTING OFF THE COUCH UNTIL ABSOLUTELY NECESSARY (like… I don’t know… get food or something).

There wouldn’t anything much to do anyway since nobody should even think about leaving the house these days.

So this is what we’ll do for the next three days and then we’ll slowly crawl out and see what else is out there. I hope you all have an awesome Christmas and a legen… wait for it… dary New Year.

And in the meantime you can enjoy the snowy view from our window.

P1010590

The Trouble With Estimates

I recently had the pleasure of being asked to estimate a set of features. I was new to the customer’s system, hadn’t been involved in any of the steps leading up to the final requirements and was still working on fixing the bugs from another project.

I sat down with the specifications and roughly estimated how long it would take to implement the required features. The estimation that came out of this was roughly two days more than was originally planned for the complete set. I also asked for a complete part of the feature set to be removed from the list and made into its own project.

So, basically in the end, I estimated more time for less work than was originally planned. Not a good thing per se, but unavoidable. As the consultant or customer you might be trying to get the developer to estimate optimistically: „Do you really need that much time?“ „Are you sure it takes that long?“ „These are just basic forms, can it really be so much work?“

The answer to that is: Maybe not, but probably yes. In my experience in every project that’s at least slightly complex, there are pitfalls. There will be trouble. As a developer I try to be as optimistic as I can get about how long something will take. But I also need to take care that I don’t end up with an estimate that will collapse as soon as I encounter even a regular-sized problem. It’s finding the balance between customer service and self preservation that is the hard part here.

Basically, I won’t give you optimistic estimates. I can’t. I won’t. The best reason not to be optimistic is that in my personal experience it hardly ever works and in the end you either have to postpone the release or you end up with a low quality product.

There are also good reasons not to be pessimistic. One is that this is a bad state of mind. I don’t want to be pessimistic. Really. I’d rather not run into problems and work smoothly on a project. Plus, it never goes over too well with whoever is waiting for the project to get done and I’d rather work with someone who’s not suspecting me of being a lazy developer.

My approach is to be realistic and factor in the risks of running into problems. This includes identifying the spots where problems are most likely to occur and allow for some time to fix these problems. Of course I might be wrong there and it turns out that where I suspected problems everything works fine. Instead trouble pops out somewhere else. Or not at all. Or everywhere at once. Who knows?

One of the best quotes I read about estimates was somewhere on 37signals‘ blog Signal vs. Noise. I don’t remember exactly, but the gist is this: Estimates are guesses. Nothing more and nothing less. They are not promises. They are not random numbers. They are something in between. And they might be wrong.

The best thing I can do is try to stay realistic in my estimates and trust that you trust me enough. I can only guess anyway.

—

I can’t find the original quote that I had in mind when referring to Signal vs. Noise, but here are two interesting posts that deal with the topic:

Unicorns and Projections

It’s not a promise, it’s a guess

Bow Down Before the Mistress of Task Domination

epicwinRemember when I said „Game base everything“? I was mostly talking about my love for Stack Overflow back then, but there are more and more examples of how making a game out of something (mostly in terms of earning points and badges) can motivate people to take part in something that might otherwise seem suspiciously like work.

Now I stumbled upon something that took one of the most boring things you know – your personal to do list – and turns it into… wait for it… an RPG.

It’s an iPhone app (also available for the iPod touch) and it’s called EpicWin. It’s fairly simple and doesn’t contain any fancy graphics, but it does the trick. You can add your items to your to do list, assign points to them and decide which of your for skills you’re levelling up (stamina, strength, intellect, social and spirit are the options).

For each quest (i.e. item on your to do list) that you manage to complete you get the points and advance further on a little map, collecting loot once you’ve reached a certain place. You also get level-ups for your skills.

Of course, you still enter the tasks by yourself. Theoretically you could just add quest after quest and advance in amazing speed, but where would be the fun in that? If you don’t need a task manager, you won’t need this app. But if you do need a little trick to manage all the not-so-fun chores that pile up around you and at least give you the feeling like you’re advancing to somewhere somehow, this might give you a bit more motivation than just plain old to do lists.

Mind you, if you need to really organize your tasks, add tags and priorisations, define contacts and so on, this also isn’t for you.

It’s for people like me who just need a little push sometimes and who like to pretend they’re a warrior princess in a fantasy world for whom making an appointment with a self storage facility sounds just a bit more fancier if it’s a quest which will add one point to your intellect skill.

You can visit their website here or have a look at the app in the iTunes AppStore here.

PS: And now I have earned my fifty points of intellect and advance further towards my next loot. Yay!

(Don’t) Lie to Me

I recently started to watch Lie to Me with the overly awesome Tim Roth. About a couple of seconds into the intro I knew it all seemed familiar, but I couldn’t quite place where I had read about it. Lie to Me is a show starring a deception expert who can tell what people are feeling by interpreting their expressions, mimics and gestures.

It was the part of the intro where they show the „codes“ that make up certain micro-expressions that I immediately recognized. It took me a while to figure it out, but the series is based on Richard Ekman, who I read about in Malcolm Gladwell’s Blink. Gladwell dedicates a whole chapter on what Ekman did, analyzing and categorizing expressions. The idea is that though we’re able to a certain extend to hide our feelings, there are certain kinds of expressions that we cannot help showing what we feel. As a bonus, they seem to be universal. Those micro-expressions are generally hard to see if you’re neither a natural at spotting them or trained to do so.

I liked the idea back when I read about it and it’s getting more attractive with every episode I watch of Lie to Me.

Then a few weeks ago we had a terrible catastrophe at the so-called Love Parade not far from where we lived. (In fact, we changed our weekend plans so that we didn’t have to use any highway or train around the area.) Twenty-one people died in a crowd when a panic broke. The next day there was a press conference with some of the most important guys responsible for the event. It was the weirdest thing you’d ever see. It was obvious no-one was going to say anything of value, since everybody up on stage was afraid of how they would implicate themselves in the tragedy. At that point I really wanted to be able to read micro-expressions. I got the weird feeling that the faces up there told a lot more about what was really up than what they said.

It makes you wonder how different the world would seem if you had the ability to recognize feelings in short fleeting moments. I can only guess it’s another example of an ability that can be both a blessing and a curse. However, it’s awfully cool to think about it and if you haven’t already you should check out Lie to Me. And read Blink. Both. In no particular order.

Thinking Differently Through Unit Tests

We don’t practice strict TDD where I work, but we make sure that we have a decent code coverage and good unit tests.

Rather than doing TDD by the book all the time I sometimes find myself with a small project wondering how to start and then coming up with the first set of tests that I know will definitely need to pass and then continute from there.

Usually, this „test first, then code“ principle only holds for so long before it breaks down and I find myself switching between writing code and unit tests in no particular order. Nevertheless, it is a good way to start and I usually cover a good deal of code before I’m straying from the pure TDD path to something less structured.

What I noticed when writing tests first is that I focus on completely different things than when I write code the before writing tests. Mostly, when writing tests first I first come up with everything that might go wrong rather than what goes right. Usually, tests for exceptions come first, then all the other conditions where things might not work as expected and last the happy path for when everything goes right.

When writing code first, it’s the other way round: First figure out how to do it, then cover the exceptions. This is probably different for other developers, but in my case it’s a very interesting observation I was able to make about myself and the way I think.

Another good place to practice TDD in small doses is bugfixing. Just write the test first, make sure it fails and then write the code to make it green. When working with untested code, it is a good way to start bringing code coverage up without having to dig through tons of code. It might not be perfect, but it’s a start

iPod Trouble and the Irony of Being Mobile

I made the horrible mistake of installing iOS 4 yesterday evening before going to bed. I had planned about an hour for evertyhing to be done, but boy, was I wrong.

To make it short, this is now my third attempt at completely restoring my iPod. One of the problems that kept occurring was that while I was doing something else on my computer, iTunes kept just popping up and as expected at least one of these times I was just hitting return, which basically cancelled the whole clean installation process. I’m pretty sure that that was end of it. From then on I kept on trying to do a full restore, but since my library consists of a respectable 3270 songs, this takes a while. Like more than an hour.

This morning I thought I’d get it done before taking off for work, but there was an estimated ten to fifteen minutes missing until the whole thing was done and I had to cancel the syncing. Now this is the third attempt and I don’t think I have another choice but just wait until it’s done, even though I might like to just go to bed. Oh, the trouble technology puts us through.

Now you might wonder why I still care so much about my iPod. It’s because so far, the Motorola Milestone hasn’t replaced what I mostly use my iPod for: Media player and little entertainment device. I use the Motorola for taking pictures and videos, using location-based services, updating twitter or simply accessing the internet (and currently checking the last results of the World Cup).

I’ve gotten so used to having access to useful information everywhere all the time that everytime I go abroad (which might include my parents-in-law’s, who live so close to the Swiss border that half of the time I’m there my cell phone mistakenly assumes it’s in Switzerland)… anyway… everytime I go abroad I feel robbed of that information. I have a very basic and unexpensive data plan, mostly because I just wanted a simple data plan which emphasized on the DATA aspect of the whole thing. I use the phone for calls and texting, but mostly I’m interested in all the not phone related activities.

I checked out a couple of options for global roaming today, but none of them catered to my needs. I don’t care for any cheap call rates or free text messages. The only person I’m likely to call is my husband and that’s about once a day at the most. What I miss is the opportunity to use all the helpful little apps that help me get around in Germany so much. Finding a restaurant in London. Checking out the timetables for the train back to Luton. Whatever. What I need when I’m abroad is directions, suggestions for restaurants and activities and information about getting somewhere and probably back. 

The options I found for simple data plans for global roaming were still insanely expensive, so it would probably cost me less to just use the options my provider offers anyway. There’s also the option of just getting a SIM from the country you plan to spend some time in, but the last person I knew who tried that was really frustrated by the process so it didn’t seem tempting at all.

Do you all just go de-mobile when you’re abroad? Do you simply not mind about the costs? Or is there a simple trick to stay mobile with your cell phone at a reasonable price? Please enlighten me. This is just s puzzle that… well… leaves me puzzled.

Settling In Properly

FxCam_1277139661894Today started the last leg of my training duties in the UK. Other than the last two times where I just came in the evening before, held a training session in the morning and took the flight home in the afternoon I’ll be here to help the developers work on a training project for the whole week. Today I got in around noon, so the taxi driver drove me directly to the office where I unloaded all my stuff and hauled my suitcase and bag directly into the training room.

Later we planned to go to Harpenden to have dinner which meant that we had to get back to the hotel first for me to carry my suitcase to the room and then catch a cab to Harpenden.

The very first thing I did when I got into the room was: Unpack. Unpack everything. Get ALL the clothes out of the suitcase. Set the books on the nightstand. Get the toiletries and stuff into the bathroom and out of their little plastic bags. Put my pajamas on the bed.

I found that this helps me get comfortable in any hotel room where I intend to spend more than one night. It might sound a little overdone, but I like to know that everything is in its place and I’m not living out of my suitcase. Even in a pretty boring hotel room it gives a feeling of having your own space.

FxCam_1277150902964After having a nice dinner at an Italian place in Harpenden (the evening was splendid, so we could sit outside) we also went to a supermarket to get some snacks. Unfortunately the biggest disadvantage of this hotel (apart from the WiFi not being free, which is like my reason number one not to stay here again) is that there’s no fridge in the rooms, so the options were limited, but I still got a decent selection of snacks that will help me to get away without having to pay for a breakfast I don’t really want while still not starving before lunch. Naturally there’s some crisps (So what? I’m in England here.) and chocolate involved, but also nuts and croissants (okay, not very healthy either) and some nut bars. And lemon flavored water, one of my favorites.

This also makes the place a bit nicer. I can see myself spending the evening watching TV shows on my laptop while having a little snack before going to sleep.

So, I have my stuff neatly ordered the way I want it plus some snacks I like. It’s not amazing, but it’s better than nothing and it helps making a hotel room far away from home feel at least the tiniest bit like something that is mine (at least for the time I’m staying here).

Un-Scare your Participants With a Few Simple Tricks

I came back from a half-day training in England last night. The whole development team is holding training sessions for a group of developers from Vietnam and the UK for about three weeks and it’s a lot of going back and forth.

I only knew four people out of a group of about 20 participants. This can be quite intimidating. Yet, I imagine these kind of situations may be just as intimidating and awkward for the participants as it is for the trainer. They don’t know me any better than I do know them. They don’t know what to expect from the training, how I will react, whether they can be comfortable asking questions, how to best address me and so on.

I find there are very simple ways to show the participants of a training that:

a) You’re just human, too. 

b) They don’t have to be afraid to ask questions or ask you to clarify something.

c) You are interested in who they are as well.

The tricks I find to work are the following:

Explain that questions are important for the training and for you
This may seem obvious, but I’d still want to mention it. Tell your participants that you want and you need them to ask questions. Tell them that this is important for you as well to make sure that what you teach them is actually clear and makes sense.

Learn their names
When I say learn their names, I mean, try to make an effort. I was holding a training for a group of people from Vietnam and UK and at one point when everyone was busy playing around with the system on their computers I walked around and tried to get the names of the Vietnamese guys right. It’s not that easy with foreign names and you’ll probably not get it perfectly, but showing an interest in learning who your participants are and what their names are and how they are pronounced is important. After all your name is important to you and it is part of who you are. Practicing someone’s name in front of the whole group also shows your participants that you are not perfect, but willing to learn new stuff.

Bring sweets
If I learned one thing in my years of working it’s that people like cake, cookies, and whatever other sweet things there are. Basically, nobody is ever too old oor too serious to not like chocolate. For the training I bought some German sweets at the airport to bring to the training and told the story of how I lived right down the street from the Haribo factory in Bonn and could smell licorice in the air sometimes. Whether it’s chocolate, cake, donuts, cookies or something else. Your participants probably will like it. Plus, bringing a bit of sweetness to your training might add a bit to the fun side of a training.