The One-Hour Bug

This is the story about one of those bugs that show their ugly faces at the most inappropriate of times, seem impossible to pin down, and turn out to be very easy to fix once you get to the root of the problem. Usually after several hours of banging your head on the table, cursing at the computer, and doubting your own sanity.

You all know these bugs, right? After spending the first one or two hours digging helplessly through code I usually say „I know it’s something stupid.“ Because I do. Whenever you run into one of these obscure bugs it’s usually one or two lines of code with a stupid, stupid mistake. These bugs are usually easy to fix. But they’re hard to find. And they will make you feel like an idiot. Always.

Anyway, as for the most inappropriate of times, how does „two hours before the sprint demo“ sound? Like an amazingly inappropriate time for a bug to be found? You betcha. So last Friday it was two hours before the sprint demo and we were just trying to check all our features for one last time, when saving a new password didn’t work anymore.

As it happened I had stumbled upon the same bug the night before. However, after a couple of rounds of re-fetching from source control, re-compiling and checking the application logs, the bug just went away. It was gone. Unreproducible. There was nothing else for me to do than blaming it on the arbitrary ways that Perforce works at times. I obviously had been working with old versions and updating the files and rebuilding the solution fixed it. Case closed.

Until the next morning when the bug was there again. Nobody could explain it. Our tester had been running UI and functional tests for days in a row. We all had been using the feature from time to time and nobody had ever come across this bug. So another developer and me went about to try to fix this ugly bug as fast as possible in time for the sprint demo. In retrospective we should have thrown in the towels and asked to postpone the demo right away. But we thought it might work.

From the logs it seemed like a trigger on the database prevented saving a new password on the base that the expiry date for a password was smaller than its create date. So we pinned it down to some DateTime issue. We tweaked the code to make sure that the create date of the new password would always be greater than the old one’s expiry date. This didn’t exactly fit the trigger’s complaint, but it was the closest we came to finding an angle to start with.

Then my colleague stumbled upon another strange behavior that made it look like the new password was already associated with the login although it hadn’t yet been persisted to the database. So we tweaked the code a little bit more to make sure that we wouldn’t accidentally expire the new password.

Since the bug occurred on two forms we made sure that the changes were implemented for both of them, compiled the code and… voilà… the bug, it was gone. Still not overly confident, but at least glad that the problem seemed to have been fixed in time for the demo, we started a new build, packed up and headed to the conference room.

You want to guess what happened during the sprint demo? Naturally, the bug, it reappeared! It was back! Naturally the feature wasn’t quite accepted and our Scrum team, well… let’s say, we weren’t exactly thrilled.

Since the rest of the demo went fairly well, it was decided that the sprint would be dragged out for a few more days to give us time to fix the bug and a couple of small things. While we were talking about how to best proceed I tried to reproduce the bug on my local installation. You want to guess again? I couldn’t reproduce it. Now the local installation had exactly the same files than the build we used during the demo. We had witnessed the bug just about half and hour ago. Now it was gone again.

We spent the afternoon hunting down what might cause a bug that re- and disappears, going down various paths until we reached a point when we consulted the database guy for some NHibernate anomalies my colleague found. Then the moment of revelation, facepalms, hysterical laughter and relief came.

Whenever we set a new password we set its create date to the current time. However depending whether we were dealing with a completely new login or just a password change for an existing password the code executed was slightly different.

Now lacking an implementation to delete logins we were mostly working with existing logins. Deleting a login required logging on to the database and deleting it manually using SQL. Not a big deal, but one that interrupted the flow and was therefore avoided as long as it wasn’t absolutely necessary.

While we were working on fixing the bug we had concentrated on the part where a password is saved for an existing login. The bigger picture revealed what the real issue was. While we were using DateTime.Now when setting the password for a new login, we used DateTime.Now.ToUniversalTime() when changing the password for an existing login.

With our server settings, DateTime.Now was one hour later than DateTime.Now.ToUniversalTime(). Since we started our demo by proudly presenting that you could create a new login that meant that for exactly one hour we were unable to change the password, due to the simple fact that the database wouldn’t allow saving a password when its expiry date was earlier than its create date.

This also explained why the bug had just gone away so many times before. After one hour of time difference between the server’s time and universal time, the expiry date would be later than the create date and the database was happy. This was a bug that occurred for exactly one hour before retreating and not showing up until the next time you created a new login and tried to change its password within the same hour.

Now, as I said, the answer, once found, was amazingly easy and clear. However the path that led to the answer was pretty much paved with confusion. It also taught us the lesson to be very, very, very careful when dealing with timestamps. Because these things, they are small and look harmless, but they can make you go temporarily insane just the same.

Defending Whiteboards

What I especially love about the video below is that it shows how utterly important whiteboards are if you want to work creatively in a team. I can’t stress this enough, and I also seem to be the greatest defender of whiteboards in our development team and the first to add „No whiteboard in conference room“ as an impediment to our taskboard.

Even now the whiteboard in our current team office is far too small for my taste. To compensate this we have pinned big sheets of flip chart paper pads pinned to the rest of the walls. My old Scrum team was located in two room, so we had two whiteboards, but that still wasn’t enough at times.

Especially during design phases you need room to sketch. In a Scrum team with five developers it is not uncommon, if not preferable, to have two user stories running at the same time which means you need two designs, which means two whiteboards is the minimum that you can work with. I would still argue you need more for any technical problems, additional tasks or just whatever pops up.

Even when you constantly erase what you don’t need, we often came to a point where the only option left was taking a picture of the whiteboard to make room for the next problem. That worked, but it is still a limiting factor when you need to organize your creativity.

A thing as shown in the video where the same content can stay on the whiteboard for days and maybe more so that people can always come back to the design, rethink and rearrange sounds too good to be true.

On the other hand, I’m not complaining. As a creative team, we find ways to be creative and work within an informative workspace. As I said, flip chart pads make a good whiteboard-ersatz for a lot of problems. They don’t provide the flexibility a whiteboard does, since you can’t easily erase stuff, but they generally work well, too. You can also get cheap pinboards at IKEA (and probably elsewhere) and use these to put up reminders. Or you can hi-jack whiteboards in other offices that are currently not used.

I still believe that whiteboards are one of the most important tools you need when working in an agile team and you can never enough.

Many Browsers and a Smarter Playlist

Today at work a colleague raised the issue of which browsers we were planning to support. Naturally, supporting a browser also means testing on a specific version of a specific browsers, which, quite simply put, means more test effort, probably more coding effort, and therefore more time spent.

After a discussion with our product owner they settled on the latest stable version of four browsers. The product we were working on before supported two browsers, Internet Explorer and Firefox, with Internet Explorer being the one to optimize for, especially since one of the third party products only supported IE. Now we added Chrome and Safari to the list.

The same colleague also complained that he currently uses three browsers, sometimes simultaneously. I realized, I do too.

On Vista I use Chrome for most things. Now I know that it lacks the tons of add-ons that Firefox offers, but I just love it. I love that the design is very simple and focuses on the actual web pages rather than menu and status bars. Mostly I love typing in anything into the address field. I’ve gotten so used to it that I forget that other browsers use extra fields for Google searches and just typing my search words into IE’s or Firefox’s address bar. If there’s one thing I need other browsers to copy from Chrome, it’s this.

However, I understand that people still prefer Firefox. The fact is that I have never actually been an avid user of add-ons. I’ve had my favorite Firefox add-ons, mostly webdesign stuff like the color picker or the ruler and these were awfully helpful and cool. FireBug as well is an awesome tool for web developers. But I’ve never heavily relied on any add-ons which might have been the reason why switching to Chrome went so smoothly for me.

I still use Firefox occasionally, though, mostly when I need one of the add-ons I have installed or whenever a page doesn’t look quite so right in Chrome (still happens).

I use IE mostly for anything that relies on using IE, which sadly happens often enough. Now, I’m not even sure whether there’s still reason to hate IE (given that we’re two versions away from IE 6 it seems like the grunting phase should be over), I just still prefer Firefox and probably wouldn’t use IE if it wouldn’t rock the whole Outlook webmailing thing and wasn’t necessary to run some of Microsoft’s web applications (yes, MS Project, I’m looking at you). Plus, of course, given that IE is still widely used, it’s the browser I most often use when developing.

What I’m trying to say is that it’s gotten hard to settle for one browser, for three reason. First, sometimes you just can’t. Some pages or web applications just run or look better on a specific browser (and some will only run on a specific browser). Second, browsers seem to have their own personalities. Chrome is awesome for the whole browsing, social, fun, interactive stuff and in my opinion just generally awesome. Firefox is great because of its vast library of add-ons and because it’s really really good. IE still beats other browsers for some of the more conservative sites, probably because a lot of sites are still optimized for IE.

Last of all, the feeling I have is that all major browsers are actually getting pretty good, so there’s not a clear winner anymore. For most people that just means that they can just pick what they like best. For a geek girl like me it means that I can’t even settle on one for good.

 

In other news I fixed a small thing that was bugging me on iTunes. I like listening to my recently added items, but since I use my iPod for audiobooks and movies as well, these files were always mixed in between, which is especially annoying when you’re on your kickboard on the way to the train and don’t have the time to fiddle with your iPod just to skip that audiobook chapter or that episode of House.

Now, I could have realized that sooner, but of course, „Recently Added“ is just another Smart Playlist and perfectly editable. The only change I had to make was filtering it down to media kind and everything was as I wanted.

SmartPlaylist

What Went Wrong With Delta

I recently tweeted about my frustration of our flight back from San Francisco with Delta Airlines. I have since then scanned a few other reviews and Delta rants and though I admit that we were comparably lucky I still would try to avoid flying with Delta in the future. Here’s why:

1. The organization at SFO was a mess. A tiny man kept pointing people in rows and though this is just an impression seemed completely overwhelmed by the task. Please note that though there was quite a queue it seemed like a totally manageable queue. Yet we were told to wait in line there then told to go to the line where we originally came from. Then they kept letting people cut the line for no apparent reason. I overheard that their flight was taking off at 6am, which was exactly the same time our flight was going and yet they seemed in no hurry to let us check in.

2. We had a little extra bag because we bought a couple of things and couldn’t fit everything in the suitcases we came with. Please beware: additional bags on Delta Airline international flights cost 50$. Now, I could have checked that on the internet, but I didn’t. So while this could be said to me my fault, it still made the mood worse. The bag was small enough to take as hand luggage, but of course we had smartly distributed liquids in all the bags and didn’t want to repack everything, so we sucked up and paid.

3. Nearly everything on the flight from San Francisco to Atlanta cost extra. Only soft drinks, coffee, peanuts and pretzels were free. Now, that I had read on the flight confirmation, so we were prepared and brought sandwiches on the place, but still. You even get stuff free on two hour flights to Poland and this was a four hour flight. They also had in-seat screens, but that didn’t really help, since all movies had to be paid extra. I didn’t check music and TV shows. Now I admit, I hardly watch movies on the plane, but it was just another thing to add to the dissatisfaction building up.

4. On the flight from Atlanta to Düsseldorf, the pillows were close to non-existent. Now, I have yet to see a comfortable airplane pillow, but this was definitely the worst I’ve had so far. No in-seat screens (which I can deal with) as well.

5. They ran out of chicken about halfway through the plane. Fine with me since I wanted pasta anyway, not so fine with my husband and even less fine with the girl behind me who had a dairy allergy and couldn’t eat cheese, which was apparently stated on her ticket but no-one seemed to care. She didn’t miss much (which I told her), since the food was pretty bad. I don’t expect much from airplane food, but I have had some pretty decent stuff on my last flights. This was nowhere near decent. Anyway, at this moment I would have expected some flight attendant to come up with a solution. Like, „upgrade“ to some business class meal or whatever, but that didn’t happen.

On the plus side, the staff on the plane was generally friendly, flights were on time. The ride was a bit bumpy, but I’m pretty sure that was the weather’s fault, not Delta’s.

I think the problem here is that I have had very good experiences with Air France so far, both on my trip to Vietnam and on the flight to San Francisco. Very professional and efficient, good service on board, manageably comfortable and actually pretty good food and drinks.

I’m pretty sure a lot of people had positive experiences with Delta and others had negative ones with Air France, but it’s still my very own experiences that I base my (flight booking) decisions on. Nothing went seriously wrong with Delta, but it went wrong enough to have me try another airline next time before I book a flight with Delta again.

By the way, the in-flight security video from Delta Airlines is Awesome (yes, capital A). I watched it with fascination on both flights and then again on YouTube, because it’s so much not what I’m used to:

San Francisco, Here I Come

The evening before the big flight and my desk is heaped with cables and electronic devices. Makes you think about how much has changed in the past few years.

Now, preparing for a vacation doesn’t just include making sure that all the trash has been taken outside and no perishable fruit is left on the counter. It’s not just checking that you have all your papers and enough clothes to wear.

No, instead I spent most of the evening looking for cables, adapters for American plugs (finally found the right ones in the one drawer after being temporarily confused by Hong Kong adapters… and why the hell do I have two adapters for my iPod charging cable???), packing my Nintendo DS game into the little pouch that came for my headphones and currently also holds the tiny iPod microphone.

Right now I’m transferring all pictures from our Nikon D70 to the MacBook, so we have a completely free disk when we start taking pictures. I should do the same for the Panasonic Lumix in hopes that then we won’t run out of disk space. After a brief discussion over dinner it was decided that the MacBook stays home (hard to believe, right?) and that we’d just buy new memory cards in case the ones we have don’t suffice.

I also need to remember to charge all electronic devices I need for the flight (i.e. camera(s), Nintendo DS, iPod and iPhone) so that they’re fully loaded in the morning. Then of course I hope to get the chance to charge them all again when transferring at Charles de Gaulle airport in Paris, just to make sure that once on the plane both the Nintendo and the iPod are charged to their fullest and get me through a ten hour flight.

(I have also refrained from playing Scribblenauts and the new Professor Layton to make sure that I don’t run our of riddles before I’m back home.)

Did I forget anything? I also took good care in syncing my iPod with all new TV show material and podcasts. So yes, I think I’m set.

I know in the good old days you brought a book for the flight and one single camera for the trip. Alas, those days are gone. Now half of my hand baggage is cables and geekie tech stuff. And adapters.

(I also have books though. We have three novels, one half-read non-fiction, two travel guides and I wouldn’t completely rule out the chance of stocking up on magazines in Paris.)

Scrum 101 – First Thoughts

We’ve been working with Scrum for a few month now and so far it has been a very interesting few months. For all of you who don’t know what Scrum is, here’s the gist:

Scrum is what you might best describe as a framework for agile developing. The reason why I’d call it framework is because it doesn’t so much tell you how to do things, but it provides a set of rules and roles that surround the actual developing. The key of Scrum is the team itself, which is self-organizing. Development cycles are usually two to four weeks. At the beginning of each cycle or „sprint“ the team commits to deliver a certain set of user stories, then works on these stories and holds a sprint demo at the end of each cycle to present their results to whoever is interested.

There’s tons of information about Scrum on the internet, so if you want to know more, you can either ask me or use your favorite search engine.

What I learned in these past months is that there are a few key things that you and your team need for Scrum to work. One of them is transparency. The other one is discipline. If one of them is missing, you might just be heavily screwed.

When I said transparency, I could have just as well said communication. It sounds so clichée, but communication really is the key. I still like transparency better because it sums up nicely what Scrum is really about and good communication is the way to reach transparency. I don’t think you can have one without the other. Or, okay, you can communicate without actually being transparent. However, I don’t see how you get transparency without communication.

When you start working in a self-organizing team, stuff gets lost. It just happens. All the time. We’ve identified communication (or the lack thereof) as one of our key problems after the first sprint and we’re still working on improving ourselves. It’s surprisingly hard.

Which leads right to the other thing: discipline. It sounds so school-masterly, but it’s true. I’m not talking military drill discipline here, just a healthy dose of get-your-crap-together. Because truth is, if you don’t, the rest of the team will suffer for it. The lack of a team lead means that the team is responsible for what they do. There’s no single person in charge or responsible.

To be honest, it is kind of scary at times. Self-organizing sounds so cool in theory and it is kind of cool in practice. It has its drawbacks though. When there’s nobody to tell you what to do, there’s also nobody to tell you what not to do, what better to do or how to do what you do. The team has to figure out how to finish their goal and often that’s not as easy as it sounds.

When I talk about discipline in Scrum I’m talking about doing the best you can to get your tasks done. But more than that, I expect you to always think about what needs to be done to get everything delivered with the best quality possible. I expect you to not ignore any problems in hopes that they go away if we don’t talk about it. I expect you to think outside of the borders of the taskboard. Also, in times of increased crankiness, I expect you to suck up and be nice. We all have bad days.

Discipline doesn’t mean working non-stop cranking out code. It also doesn’t mean sticking to fixed rules and doing everything by textbook. And it should never ever mean not having fun.

Working in a self-organized team requires communication, transparency and discipline, because as a team member I depend on the rest of the team. In short: I need to trust my team to be able to work effectively. So I’d like to add trust as another key word for Scrum teams, but that’s a story for another post.

Theresa Neil on Designing Rich Applications

I considered just quickly posting this on my Tumblr blog, but I think this fits in here very nicely and probably better. Have a look at the Theresa Neil’s slideshow on designing rich applications. I especially like that the slides are pretty self-explanatory, so that you don’t feel you’re missing too much without someone commenting on what they actually mean.

Designing Rich Applications

View more documents from Theresa Neil.

 

The slideshow was published as a part of a blog entry. I also like the idea of having a flip book to browse for UI design ideas. In fact it makes my fingers a bit itchy and I’d like to just start one of my own if I only knew how to find enough time to make one.

Inline Validation, Good and Not So Good

I keep on stumbling about the whole inline validation design pattern these last days. It started with the sign-up form for boxee, then was followed by an article at A List Apart and today I was just fascinated by how one single company could get it so right and so wrong at the same time.

Let me start by saying this: I’m a huge fan of inline validation. I think it rocks. It does have its problems, but I dig the general concept and I’ll fight for inline validation over validating on save any time.

The boxee sign-up form is a great example for everything that’s good and pretty about inline validation:

Boxee Signup

 

Helpful error messages, good choice of fields that can benefit from inline validation and a nice and clean design. I know exactly what I did wrong and what I need to do to make it right. I also get positive feedback for fields that might have issues (i.e. the username which may or may not be already taken) that I need to be aware about.

Before I go too deep into the details of inline validation, I’d like to point everyone to the article „Inline Validation in Web Forms“ by Luke Wroblewski at A List Apart which sums up a usability test with various forms of (inline) validation. While the article states that inline validation is generally a lot better than validating all input at once after the user has clicked Save (or completed a similar action), there are also some drawbacks and considerations when applying this design pattern. Basically, inline validation is good, but you still need to figure out how to use it for what you want to achieve.

Today I wanted to sign up for Club Nintendo, just to have a look. The first attempt failed because I tried to sign up on the US page and didn’t notice until far along the signup process that I was on the wrong page. However, I got a glimpse at how inline field validation is used here:

Nintendo US Signup

Apart from using a progressive disclosure pattern (which seemed a bit over the top here, but wasn’t actually disruptive) inline validation was nicely used for checking whether my chosen username and/or preferred screen name was still available.

The password fields didn’t use any inline validation, which makes you wonder a bit. Password fields are a brilliant candidate for inline validation, but apparently this wasn’t considered here.

However, when I switched to the European site, I got to use the following signup form:

Nintendo Europe Signup

Never mind that it’s in German, I still think you get the point. I don’t care so much about how the US form used a step by step approach for filling out the form and this one just has everything on one form. Either way was fine by me.

However, although inline validation here was nicely used for the password fields, it was completely unhelpful. It told me that my password was invalid. But. It didn’t tell me why. Nowhere on the page could I find any information on how my password should look like to be accepted. This is definitely irritating and annoying. Applying inline validation and then refusing to give any reasons for wrong input seems like the UI design version of „It’s the thought that counts“. Unfortunately in this case, it’s not. If you want to do it right, do it right and don’t stop when your halfway there.

Inline validation is a great way to give immediate feedback on the user’s input and help them fill out a form correctly with the very first try. But it only works if you provide helpful and clear information as well.

 

PS: I finally figured out a password that worked. My guess is that Club Nintendo Europe doesn’t approve of any symbols in their users‘ passwords. Not sure who thought this would be a great idea. I don’t agree. And I also don’t know whether this actually was the reason.

Coding Nostalgia

Jeff Atwood over at Coding Horror wants to know where all the COBOL programmers are.

Well, one of them is sitting at her computer typing this. To be fair, I haven’t written any COBOL code in more than four years and even when I did I wasn’t that enthusiastic about it. But still, I did my apprenticeship in an IT company providing services for some of the major insurance companies in Germany, so guess what language all their programs were coded in?

Here’s a quote from Jeff Atwood’s article:

If these 220 billion lines of COBOL code are truly running out there somewhere, where are all the COBOL programmers?

I think it’s safe to say that a lot of them just ran. I didn’t exactly run from COBOL and the fact that I wrote code in MUMPS after my COBOL gig probably is prove enough, but I wasn’t sad to leave it either. However, it might have been one of those experiences that in retrospect don’t seem that bad and leave you with that superior feeling of been there, done that.

COBOL is indeed a strange language, and to those who are not familiar with its strangeness, here’s a quick introduction to its weirdest character traits. 

  1. Fixed divisions and sections. Start with the IDENTIFICATION DIVISION, move on  to the ENVIRONMENT DIVISION with its INPUT-OUTPUT SECTION, then on to the DATA DIVISION  to define yourself some fancy variables. Only then can you start writing actual code in the PROCEDURE DIVISION. It’s kind of awesome and insane at the same time. You can’t mix up any of the divisions, there’s a fixed order and you can’t define your variables anywhere else than in the DATA DIVISION.
  2. Defining variables itself is a blast. First, you have to define them all upfront, which is not that unusual, but still. Second, you have to set a size. I mean really set a size. Like, this is a string and it’s 30 characters long. This is an integer and it’s 6 digits long. This is a freaking decimal and it’s 4 digits and two decimal places. No re-defining during code. I think apart from the fact that COBOL doesn’t provide a modulo operation which left me with no choice but naming a variable „USELESS“ once1, this was the part of COBOL that annoyed me the most.
  3. This doesn’t have to do with COBOL directly, but I’d like to throw in JCL. JCL – or Job Control Language – was a scripting language that could at best be described as cryptic and was needed to actually run the COBOL programs. I’m pretty sure that in the whole company there seemed to be only one guy who actually understood the language. Everyone else was doing it the copy/paste/pray way. Maybe I’m wrong, but that’s what it seemed like.

No, I don’t miss writing COBOL code. But maybe it was worth learning how to write COBOL anyway. First of all, I am one of those COBOL programmers. Plus, you can always tell one of those coding nostalgia stories at lunch and get that glassy look in your eyes remembering the time when you spent hours a day writing those copybooks. Good old days.

It’s even more fun though when you get me started on MUMPS. Because that, my friends, is one fucked-up language.

1How do you work around that? Well easy, you can use a division and the save the result and the rest. Unfortunately you have to store the result, which when you really only need to use the rest, doesn’t leave you with any choice, but to passive-aggressively name your variables the only way they can be properly described: useless.

Mini-Blogging: What’s Eating My Time

It’s been pretty quiet here, but there’s a reason for that and since it won’t fit into 140 characters and I do feel a bit bad about not writing anything at all here, I thought I’d give you a short heads up on what I’ve been up to these days.

Here’s the thing. A few weeks ago there was nothing on TV which made me tell my husband that I was thinking of buying a Wii somewhen soon which made him dare me to buy one right that evening. By the way it was about 7pm when this happened, which meant that we pretty much ran out of the Italian restaurant, jump into the car and drive to the next electronic store. There I pretty much stopped the first guy to walk around in the games department and said something to him, which can easily be translated into: „We’d like to spend lots of money. Sell me a Wii and whatever equipment there is.“ Which he did.

So we’ve got a Wii. Of course we also bought the Balance Board right away, plus two additional games, so we’re set for now. Can’t wait for Wii Fit Plus to be released though. I want that chicken suit!

I also still have that Nintendo DS I got for my birthday last year. I’ve been pretty bad with buying games for the DS. Of course I’ve got one of the Dr. Kawashima’s which I’m pretty sure everyone has. I also have one of those hidden object games, which was a bit of a letdown (I have a similar game on my iPod which I loved). I got Professor Layton’s Curious Village which was so awesome that I dragged it out because I didn’t want it to end.

And since last Wednesday I have Legend of Zelda: Phantom Hourglass.

Conincidentally, last week was also the week when the first part of Monkey Island was released for the iPod.

So, let me get that straight for you one last time: There’s the Wii, Legend of Zelda and Monkey Island. Do you need any more explanation on why I can’t seem to make time to blog?

I thought so.