Kategorie: Developing

More Whiteboards Everywhere

I wrote a post about my deep love for whiteboards a while ago. This is a short follow-up with a revolutionary (well, not quite) idea that I’m proposing to development teams everywhere.

We’ve been jokingly talking about that at work, but I think it has a good point: We have our little office kitchen, basically the heart of the whole office floor because it’s where the coffee is. Often enough, kitchen small-talk turns into a design session, some technical issue gets discussed, a specific problem is brought up and so on. You probably know what I’m talking about.

So, what if we had a whiteboard in the kitchen? It would make total sense and would be perfect for turning a kitchen discussion into a design concept. Draw it up, take a picture with your cell phone, go back to work. It’s the spontaneity that counts here and having an easy way to jot down ideas would bring this to a whole new level.

Game-Base Everything

I recently joined StackOverflow because we had some problems with FxCop that nobody could really explain, so the last option was to register for StackOverflow and ask there. I’ve noticed for some time now that this forum provides what are most probably the best answers to any development problem up to the point where I would add „stack overflow“ to any Google search regarding programming issues.

After asking the question and waiting for the answers I realized how immediately infecting the reputation-based system of StackOverflow is. There I was with my sad little 11 reputation points, 1 single badge and one question with no votes so far. If your the least bit competitive and a tiny bit insane, that’s going to bug the hell out of you. After all, you want more points, more badges, more votes, more reactions. At least that’s what happens with me.

So, I started to poke around the rest of StackOverflow, found questions to answer, added comments here and there and slowly my reputation points went up. Another nice side effect is that this blog gets a bit more traffic. Don’t know how many people stick around, but it feels good to gradually get more hits from all over the world.

The genius of StackOverflow is that reputation points are based on the rest of the community not on sheer input you feed into the system. In other words: StackOverflow rewards quality, not quantity. Most other online forums simply reward the quantity of posts with some kind of reward system. It doesn’t matter whether you post a detailed problem solution or just a „Okay. Thanks. I’ll try that.“ Your posts will be treated the same.

StackOverflow on the other hand won’t give you any reward until someone else from the community says that your answer or comment is actually worth it. Plus, there’s a penance if your fellow StackOverflow users thinks that your question or answer is kind-of-crap. The effect is that people are forced to actually think about what they’re writing (be it a question or an answer), rather than just typing in some unreadable, unclear and basically not-thought-through stuff and hoping that everyone else will just ignore that you obviously weren’t willing to spent a few minutes on thinking about what you’re writing.

It also makes sure that the answers for the most time are a lot better than in most other forums, because an answer that is either wrong, incomplete, unhelpful or just hard to understand will probably not be getting you any points and therefore probably not worth writing at all.

How I think about this, I am pretty much assuming that most users of StackOverflow share the little competitive and game-affine trait that I have. But, yes, I think they do. I think that getting points and climbing up in some kind of hierarchy is something that is addictive to most of us who spent a lot of their time at the computer even when they’re not at work. It just gets us. It’s what makes so many time-wasting small web games so popular. It’s what makes location-aware services like Foursquare and Gowalla work. Because, let’s face it: We all like to play rather than work. And if you make what we would otherwise perceive as work seem like a game to us, you win.

So adding a game-like feature to something that is actually more than a game is pure genius. It makes a forum that probably would have been very good anyway an amazingly great forum. So I salute whoever originally said „How about we make it reputation based, but… different?“ It was a great idea. And it worked.

Should Sprints End on a Monday?

Last week was the final week of a sprint and things were starting to get emotional. We were running out of time and probably the only reason we made it was that people were staying late to finish up stuff. The last day before the sprint demo, we were testing three forms, praying that we wouldn’t find anything that would need fixing and push us into another round of testing.

We were mighty lucky. No major bugs were found, and we only had to do a second round of testing on one form before I could leave on Thursday around 8pm – and out of the four of us I was the first to leave.

Then again, the sprint demo went really well. Everything worked, we could answer all questions, we were prepared, we had a list of bugs that we knew were there but couldn’t do anything about it. Two small bugs popped up during the demo, but that was okay and the sprint was successfully signed off by the product owner.

That was a Friday. We usually have the demo in the morning and the retrospective in the afternoon. However, the team was pretty exhausted, and I was fighting headaches, so I asked for the retrospective to be moved to Monday.

Today we had the retrospective and it went well. We could focus on the problems we had and come up with action items to help us avoid those in the future – just what you should get out of a retrospective. In fact, I personally think it was one of the best retrospectives we had.

I wonder whether it would have gone equally fine if we had dragged our sorry tired behinds to a retrospective after two long nights and nearly one and a half hours of sprint demo. There were a couple of not-so-nice things that had happened during these last days and I still felt pretty emotional about those. I can do pretty well with sucking things up, but a retrospective is all about talking about what went on during a sprint, so I wasn’t sure how well I would hold up.

My feeling is that while you should absolutely do a retrospective right at the end of a sprint it might be a good idea to do it on a Monday instead of a Friday. There’s a whole weekend between the last day of the sprint and the retrospective and it can definitely help calming things down. A weekend gives you time to let go of all the emotional stuff and get a bit of distance while still keeping memories fresh enough for a productive retrospective.

This leads to another idea. What about a sprint demo on a Monday? This could have two advantages:

1. The sprint team and everyone else involved can come in refreshed after the weekend, possibly with more energy than they would have on a Friday.

2. If the team runs into the unfortunate situation of not getting it done, they still have the option of working on the weekend. I know this is not something that people like to do, but in some cases working a Saturday might still seem like the better option than failing a sprint. Basically, having a weekend between the last day of the sprint and the sprint demo gives the team two days they could use if things go very wrong.

I wonder if this is worth a try for the next sprint. If we actually do change the schedule, I’ll keep you posted on whether it really makes a difference (and – if yes – whether it actually is better).

Fun with Yahoo Pipes

pipesI know that Yahoo Pipes has been around for quite some time, but I have never had a use case where I thought I needed it. Frankly, I only had a vague idea about what it was.

That is… until today. I’m still not totally clear about all the things the pipes can do for me, but there’s one thing that I now know they can do: help me build an automatic retweet bot.

Admittedly, this was a fun project whose other purpose was to keep me sane after more than two straight days of configuring security for nearly two hundred objects (don’t ask, you just don’t want to know), but it was quick and successful and now that I’ve tried it I wonder what other cool things I could pipe together.

I started with this video, which is a step by step guide as to how to build an automatic retweeter. (Actually, once you’ve watched this you can pretty much stop reading here. On the other hand, it would be nice if you’d read on.) Fortunately what I wanted to do was even simpler. I just wanted to retweet everything from another tweet account.

 

Setting up Yahoo Pipes

1. Create a Fetch Feed module and add the feed you want to retweet.

2. Create a Filter module and block everything that has RT or *.RT in the item.title. This prevents you retweeting retweets and risk running into an endless retweet. Also block everything where the item.title starts with @ to prevent retweeting direct mentions. Link this module with the first one.

3. Create a Loop containing String Builder to manipulate the item.title. In my case I added some text and an @ to the start of the string to simulate a retweet with comment. Then assign this to item.title. Link this module to the Filter module.

(Note that I’m pretty sure that using item.description would have worked just as well, since it looks like Twitter doesn’t really care to differ between the two.)

4. Connect that last module to the Pipe Output and check it out.

 

Feeding your Twitter account

Now, there’s a handy tool called twitterfeed which will take any feed and route the output through to a selection of services, including Twitter. You just define the feed you want to use as your input, link to it your Twitter account (Facebook and a couple of other services work, too) and you’re ready to go.

You can define multiple inputs and multiple outputs, define which part of the feed’s items you would like to pass on (title, description or both) and define the update schedule (30 minutes are the shortest refresh cycle). There are also a couple of other settings like setting prefixes or postfixes or filtering the input feed, but I didn’t have to use them.

With that all setup I had to be very patient to wait until twitterfeed finally sprang into action, but it worked perfectly.

Now, this was a pretty useless project in terms of actual results. I’m retweeting someone else’s tweets. As far as making the world a better place goes, this doesn’t help a lot. Still, for a quick introduction to Yahoo Pipes this was a great way to start. Now I keep wondering what else I could pipe together with a more useful output. Any suggestions? Experiences? Ideas?

That Calm Before the What?

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.

What Code Coverage is Good For

There is a common misunderstanding regarding code coverage of unit tests. To make it short: Code coverage doesn’t tell you anything about whether your unit tests work. The only thing they tell you is which code lines are covered with the unit tests in place.

A lot of times it is very, very easy to achieve 100 percent code coverage with a few simple unit tests. If the unit you’re testing doesn’t have any conditions you might get away with one test which will execute every code line and get a perfect code coverage score.

Well, duh. That doesn’t mean your code is thoroughly unit tested.

However, there are good reasons why you should look out for code coverage and reach for the best coverage you can get. I usually only check my code coverage at the end of a unit test writing session. If I thought of everything I should get a 100 percent coverage. If the code coverage is less than expected it’s a good chance I missed something.

In other words, just because your code coverage for a tested unit is great doesn’t mean that you’ve tested everything. It also doesn’t tell you whether your tests are actually correct. The brainwork is still up to you and any code coverage analysis can’t help you there. However it’s a nice way to make sure that you didn’t forget something obvious, like forgotten to test the other condition.

I regularly run PartCover to check code coverage of implemented features and I regularly find untested code lines. Most of the times these are due to small changes or bug fixes, when we just forgot to add a test for that simple change we made.

So, while code coverage tells you nothing about the quality of your unit tests, it is a great way to find any open gaps – however small or big – in your existing tests.

Everybody Loves a Code Review

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.

Ensuring Good Passwords: Reward or Restrict?

We’re currently in the designing phase of a password rule configuration form. At first this sounded easy, but after a couple of discussions it turned out that the whole password strength and rule configuration topic is a pretty delicate one once you start digging deeper and questioning what you originally have thought was unquestionable.

The basic question here is „What does a good password make?“ where good actually means strong. The other question is „How can we get users to choose good (i.e. strong) passwords?“ – and that’s where the trouble starts.

The problem is that there’s a lot of tension when it comes to getting users to choose good passwords. There’s tension that you might never resolve and just have to find a compromise and there’s tension as a result of a false sense of security and policies established around that sense.

An example for the first type of tension is one of the basic problems of good passwords: The stronger a password, the harder it is to remember. It would be great if everyone chose a 24-character totally random password and had a different password for each service and application they use, but that’s just not going to happen. So, we need to compromise on the strength of a password in order for people to be able to remember it.

Of course there are tools that help organize our passwords, but let’s stay real here – this is not something that for example my parents would use. If I were to install KeePass on my parents‘ computer and tell them to use 20-character randomly generated passwords from now on, my mother would stare at me blankly and tell me that she was doing just fine with her passwords.

Now there are two ways to go from here: I’d call them restriction or reward.

Restriction means defining password rules that users have to comply to. Minimum length, use of numbers, symbols and uppercase characters, and so on. I can also force users to change their passwords every two months and prevent them from using any of their old passwords.

Reward means rewarding users for choosing a good password. It’s a bit of an ‚attaboy‘-reward, but still. Whenever I sign up for a new service or change my password, I like to see the password validation bar go from red and weak to green and strong, telling me that, yes indeed, the password I chose is strong enough to protect my account sufficiently.

The problem with restriction is that it doesn’t guarantee good passwords. If you take the most common password rules, minimum length as well as required use of numbers, symbols and uppercase letters, you can still choose Admin,1 as your password and be good to go. Requiring users to change their password after a defined period doesn’t help either. The user who chose Admin,1 initially will just change the password to Admin,2 to satisfy the required password change.

A strong password doesn’t need symbols or numbers. It simply needs to be hard to guess. A good password is a random set of characters and that’s something that’s hard to put into configurable rules.

Restriction and reward don’t really contradict each other, but they’re different approaches of how to educate users to choose good passwords. There’s a difference between forcing users to adhere to a set of rules and rewarding them for making sensible choices. And there’s tension everywhere: How far can I go with configuring rules to enforce good passwords without seriously annoying users because none of their passwords are accepted? Huh?

As I said, there are a lot of questions here and I’m not done thinking about it.

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.