Deviation Alliance

Now I’m one of founders of a new blog initiative – Deviation Alliance. If you liked what you read here – you’ll like what we have there, at http://deviation-alliance.com.

Also, follow us on Twitter!

P.S. All my new posts will be available there and not here, sorry.

What Developer Needs From a Bug Report?

Really – what information should be mentioned in a bug report? Yes, you know about these things with High, Highest, OurBusinessHasBeenDestroyed priorities and severities, everyone knows about them. But does anyone know what is really needed from a bug report? I had a nice time working as a QA engineer at the start of my career and I’ve learned some things that, combined with what I learned while being a developer and mixed with what I’ve read about, form this post.

Let’s all become goal-oriented and define a goal of any bug report. The final goal of each bug report is to eliminate the bug this report was written about. It doesn’t matter whether it will be fixed or considered not a bug but feature – the bug should be eliminated anyway.

The key to problem solving lies within understanding the problem. In case of a bug, bug report is used for that. Thus, it should contain all necessary information for understanding the problem. Two possible sides of detailing report are simplicity and complexity.

What’s the simplest bug report should contain? It should contain the description of the problem, it’s application. It’s like a smell. If someone enters a room with a nice perfume – you’ll smell it. The simplest bug report should just describe this smell. This way developer will have to spend much time reproducing the problem.

What’s the most complex bug report should contain? It should contain info about:

1. Full description of bug, and more strange bug gets, more details QA should provide
2. When did it appear, with millisecond precision?
3. What actions caused it?
4. Where was QA located in application map - page, screen, etc.?
5. What environment caused the bug - OS, browser?
6. Did QA do anything unusual before detecting the problem?
7. What context produced this bug? Maybe it was during version update or hacker attack?

It should also contain information on how to reproduce – that’s very important. Describing steps for reproducing a bug is not easy at all:

1. It should contain conditions that make the bug happen
2. It should not contain conditions that do not affect bug appearing
3. It should contain conditions on how to avoid bug

Moreover, instead of describing problem implications only, complex bug report should suggest problem roots. Yes it’s much harder but damn we’re talking about complex report! QA should analyze provided problem implications and suggest what could cause the problem.

Yes, complex bug report really differs from a very simple one – but using it for bug solving will be much easier and you’ll always get positive feedback from a developer. However, you should be aware of the 80/20 rule: 20% of work takes 80% time and vice versa. This means that you should always consider all options and just think – some information is much easier to get for developer, not QA. Don’t waste your time thoughtlessly – you may reach 90% complexity and this will be enough.

Test thoroughly and report well :)

UPDATE: updated bug description criteria to be more specific.

Windows Phone 7: Binding to ApplicationBar properties

I’ve been playing recently with WP7 development and transitions in particular. In some cases you need to change your ApplicationBar with respect to some ViewModel properties. Edit mode or some NullPattern for bindable list may be good examples for such situations. I wish that thing was easy or obvious (if it is easy but I could not find it :)), but I had to work around this issue with DependencyProperties and manual binding.

Let’s start of a dream:

This is an ideal variant: simple binding and everyone is happy. However, this particular example raises an ‘Invalid XAML’ error. This error makes me think that may be there is a correct way to do what I’m doing but I'’m satisfied for now with my solution.

So what are we going to do? We’re going to do the following:

1. Detect DataContext change (this is our ViewModel we should update our ApplicationBar according to)
2. Detect change of property we should bind to and update ApplicationBar respectively

We’re going to use dependency properties for handling necessary changes.

First, let’s handle DataContext changes:

Here we are defining a CustomDataContext property which is bound to DataContext property of our MainPage. We don’t specify binding property because it will default to DataContext – just what we need.

What should we do in our handler? We should start listening to desired changes and handle them. How? Quite the same – using yet another DependencyProperty:

We’ve defined what reaction we expect from ViewModel property change. Now we have to tie it together with some specific property in our data context. This action will take place in the DataContextChanged handler:

So here we bind our ExtraListNotEmpty dependency property to ListIsNotEmpty property of our ViewModel. Moreover, we explicitly call UpdateApplicationVisibility method that updates ApplicationBar visibility according to specific parameters. We have to do this because by default binding won’t ask for value until it changes – but we need this update at the very beginning.

Let’s finally have a look at the code all previous lines were supposed to support:

ListNotEmptyChanged handler is very simple – it calls UpdateApplicationBarVisibility method we’ve already talked about. This method takes current data context and decides whether we should display our application bar or not.

If someone find another way to do this – please tell me. I really want to replace all this code with the single binding line I’ve shown in the very beginning.

Organize Your Bookmarks

I browse web on everyday rate, it’s a part of my professional education and I really praise the Web for opportunities it gives me. I surf through pages here and there and sometimes I find something really interesting I just have no time to read now or something that should be saved for later. That’s the case where bookmarks save the game.

Bookmark is a simple tool that allows you to save a link in your browser and access it later. This tool may seem so easy and obvious that people just stop paying attention to bookmark organization and they end up with UI mess. So what to do? I suggest using principles borrowed from people who work with papers every day. They have several folders on their desktop that contain different items. Let’s think how to apply it to bookmarks management.

First, we need some folder to contain all input not processed bookmarks. Let’s call it New folder. Any new bookmark you want to add but don’t know where exactly it belongs should be placed here. You should process this folder at least once a week to avoid cluttering. ‘Processing’ this folder means moving items from it to trash can or to other folders.

Second, we need some place to store links that we’ve read and want to save for future. Let’s name it Info folder and use it for these bookmarks. The problem is that usually we have a plenty of links of such type so we need inner categorization. As for me, I have folders ‘Windows Phone 7’, ‘Presentation’ and ‘Neural Networks’. When I place some bookmark to Info folder I decide whether it belongs to folder root or needs categorization. When there are too many items of same type in Info root I create an appropriate subfolder and move them there.

Third, there are links that require some action, like buying, downloading, blogging, etc. The Todo folder is a nice place for such items. My Todo folder contains such subfolders as ‘To buy’ (with yet another subfolder Books), ‘To download’ and ‘To blog’.

The only thing that remains uncovered is a bunch of links that we access every day, such as issue management dashboard, mail, RSS reader, etc. I have two main items: JIRA dashboard and AgileZen dashboard – so it’s rather logical for my folder to be named Dashboards. You may name it as you with.

So, we ended with the following categories:

1. New – for new items
2. Info – for items that need to be remembered
3. Todo – for ‘call to action’ items
4. Dashboards – for links that we access every day

Almost all modern browsers have out-of-box or extension-based bookmarks sync tools. I use Google Chrome and it’s really awesome to access my bookmarks at any PC I use (actually, three of them).

And just one more thing to remember: clean your bookmarks once a month. They may become outdated or not interesting to you. Don’t show mercy – eliminate them in the name of Order and Productivity.

The Importance of Reading Books

The title of this post may seem rather obvious, but believe me – it’s not obvious for many many many programmers all over the world. These people ignore books as a source of information and by this they basically slow down their professional development to turtle speed. I hope you’re not one of them! :)

WHY do we need to read? From the primitive point of view, there are two ways to increase skills: theorize and practice. As with all opposite things it’s crucial to find a balance and is a complete mistake to shift entirely to one side only. People who theorize only will always fly in the sky with no practical implications of their knowledge. People who practice only will never have enough knowledge baseground for really full and hard practice. While programming provides you practice, reading is the only way to improve your theoretical background.

So, WHAT to read? One very important point to remember about reading is be balanced. Yes I know that’s just I said before, but in this time the edge cases are different. Programming books are only one edge but I recommend you to have a look at these ones:

1. Fiction (science, fantasy, pulp) – fiction is a really good source of inspiration and relaxation
2. Psychology – this one may be strange but listen to me. We all communicate on daily basis, communicate not only with computers, but also with real people. And if we think natural to improve our skills of working with computers – why not improve our skills working with other people? As for me, I read psychology books just because they are damn interesting!
3. Art – from all points of view I prefer to think of programming as of an art. We create, we construct, we imagine, we innovate.
4. Business – this category includes all books about time management, career management, success stories, marketing. You may think why you have to read books that cannot be directly applied to your profession but you’re mistaken about their implication. Most business books can be directly applied to programmer’s work. Success stories are about how to achieve what you want. Time management is the basis of project and team management.
5. Project management – this one is very obvious – we all meet PMs every day and some of us are PMs :) Let’s try to understand these people and finally know what they want from us!
6. Presentation – I differ these from Art category because they’re more about explaining, not expressing. Your idea is worthless if you can’t present it.

You may concentrate on two or three of these categories but I inspire you to pay attention to all of them and find your own areas of interest.

WHEN AND WHERE to read? I usually hear from many people - “When should I read these books? I have no time!”. When – any time you’re wasting your time waiting for someone or something, any time you are doing nothing useful – like moving in the underground. You can easily find time for books if you really want this.

HOW to read? Of course you should read all books the way you prefer most, but you should remember some basic principles:

1. If book has some points to think about like a patterns book – “schedule” some time to think about it. It’s not actually a time planning – just don’t read chapters one by one. Read several points and stop reading for some time. Think about these points when driving or anywhere else. Return to reading only if you are sure you have processed information you’ve already received.
2. Don’t read trash books. Yes, there are horrible books and there are a plenty of them. Try to find book reviews before reading it or subscribe to some passionate reader who’s not lazy enough to write book reviews in his own blog (just like me :))
3. Read only things that are interesting. If you’re reading something that is not interesting to you – you’re wasting your time because nothing of it will stay in your head after you close this book. However, if you know this book is damn important – change your attitude to it and make it interesting :)

And now, stop reading this and go find some interesting book!

Using AgileZen for your career management

What is your career if not yet another project? It has it’s own iterations, goals, results. So why not manage it like a project and don’t leave it uncontrolled? I do recommend you doing so and use any project management tool for that. In this post I’ll cover basics of career management using AgileZen as a wonderful example of project management tool.

Goals are main units of career management. You usually aim for something and try to reach it – that’s a nice thing to plan and control!

Basically there are several phases (or states) for your goals:

1. Backlog – a pile of goals you haven’t yet assigned to any other phase. All new goals are placed into this phase automatically
2. Permanent goals – this is something you have to keep in mind almost every day. These goals usually are abstract and have no concrete steps. “Improve communication skills” may be an example of such a goal.
3. Long-range goals – such goals are something concrete like “Study Domain Driven Development” but you didn’t plan to reach them in the nearest future.
4. Short-range goals – such goals are also concrete and differ from long-range goals only in execution period – they will be started in nearest future.
5. In progress – such goals are executed right not, for example, you have started studying NHibernate
6. Complete – such goals are history

Each goal starts in backlog. If it’s a permanent goal – it will reside in Permanent goals section and will most likely go directly to Completed phase in the future. If it’s something concrete that should be done – it will be moved to long-range goals, then to short-range goals, then it will be started and then moved to completed goals. This is an example of career board:

AgileZen is really useful for organizing these phases and usable for creating goals and moving them all around. Goals in AgileZen may have subtasks that can help you to structure your task and complete it step by step. What is awesome – AgileZen has a Free plan that is available for single project with a single person – just what we need for managing our careers.

I use AgileZen for my career management, blogging and education and I’m absolutely happy with it. Go try it and be in control!

Book Review: The Back of the Napkin

Due to my profession I often find myself explaining something to someone and more and more times I catch myself on grabbing anything I can draw with and start visualizing my ideas. It’s just much easier to explain if you have some visualization points you can easily roll back to – just pointing at them with your finger. All I knew about visualization was intuitive so it was really great to find a book that covers visualization in depth – The Back of the Napkin by Dan Roam.

This book is very good in organizing your mess of intuitive visualization ideas into clearly distinguishable piles of sorted ready-to-use ideas. Dan is an expert in applying ideas visualization to solving business problems and throughout his long career he extracted some basic principles and patterns that are now presented in this book.

Dan explains the process of processing information and presenting it to other people. He describes how information enters our eyes, enters our brain, transforms into adequate understanding and then is presented to listeners. Then Dan looks at each phase in details, highlighting most important aspects of it. You’ll know what questions use to universally analyze any situation (the 6W principle), how to choose what edge to pick (SQUID system) and how to wrap this all with logic and defeat your current problem.

All these principles and patterns are wrapped with interesting real-life stories and are very easy to understand when reading the book. Go get one – you won’t regret it!