Why I love to write stories while I’m programming

When you program something that involves complex logic it's very easy to jump in head first and start typing away. The first couple of projects I did started like this, they weren't very carefully planned out which meant that requirements would change all the time. This often resulted in buggy code and forgotten features.

When I started working with other programmers who were young and inexperienced like I was, I noticed that many of them struggled with the same problems. We would encounter weird bugs all the time and we'd curse those silly users for wanted strange things. The things users want are, in fact, seldom strange. Users might not be able to articulate what they want but more often then not their wishes are genuine and real.

Starting to define projects

When I learned more about programming, I learned that planning and defining requirements is extremely important. So whenever I started working on something I'd start thinking about it. I thought real hard for several minutes before I started to model my data. And then I thought some more and remodeled my data. And I'd think about features, and then I would build them. And I felt great, everything seemed so organized because I actually thought it through.

But then those pesky users came along. Still finding bugs. Still missing features. And I would have to go back to the drawing board, remodel data, break everything I had built just to allow a user to edit something they did before. At this point I had realized that most features users complained about were actually good features. For example, editing something. Users make mistakes, they should be able to correct them. It seemed so logical to me, the system asks you "Are you sure?" and the user responds with a "Yes". The user was sure so why would they need a way to undo it, or edit it. Well, we all make mistakes and a system should be kind to it's users.

Write it down

In order to not forget features I would write down lists at the beginning of a project. Often these lists would be written down really quick and I'd use pen and paper for this. The list would contain features, data flows and they would be written from the perspective of the application. This helped me a lot but it still wasn't perfect. I would still forget about users in a way that was very annoying for myself. And the people that used the things I built were probably a bit annoyed as well.

So, when I got some bug reports in I would quickly write them down, redefine what I was going to do and off I went, fixing bugs and making the world a nicer place. But you can probably already guess. I'd still forget things. I sometimes shared my lists with others to make sure I didn't forget anything. Usually I didn't seem to have forgotten anything until we started some real world testing. So, what went wrong here? I had lists, people gave feedback, all should be good right?

The user story

It wasn't until I started working on a very large, internal project at Rocket Science Studios that I learned how to properly define features. One of the senior developers wanted to approach the big project with user stories. These stories would outline how a user interacts with the application. The stories were never very long and they would never take into account how the system works. So no mention of AJAX or MySQL, just user related actions. A user story we wrote would look like: "When I add a new item to the canvas I want it to be placed in the center automatically". Or "If I move something around I want it to be saved automatically". Or, one more example "When I lose my internet connection I don't want to lose my changes if the browser window closes".

When you have user stories you start working with something real. You start thinking like a user and you start thinking about how a user actually interacts with your application. And when you are in that mindset you probably become more critical of your own work. When a user wants something to happen they probably want it to happen smoothly. They probably don't care about technical details, they just want to do things.

In conclusion

In the years that I have been learning how to build web applications I tried several approaches to building features. I've learned that doing things quickly seldom is a good idea. An even worse idea is to keep all the information in your head. You're probably way too busy to actually remember everything, sometimes over the course of several days. Another thing I've learned is that users don't care about details. A user wants to do something and they want it to be smooth, it's our job to make that happen.

A tool I enjoy using is the user story. This tool is a simple, effective tool that forces you to think from a user perspective rather than an application perspective. This forces you to carefully plan and think about features in a more user centered way. And this often results in making things smoother, more logical and less buggy. So, my advice to anyone out there reading this is to try user stories sometime. Maybe together with your whole team, maybe just for your own features. And chances are that you will write better applications.