Being Cellfish

Pugh Decision Matrix

2009-11-13T05:45:00Z

The Pugh decision matrix is a is a tool to help you make decisions when you're trying to sort out what alternative is the best but they all have their pros and cons. It can also be used to help a group decide on a decision. The way it works is that you first list your alternatives. And you also want to have a default decision (usually doing nothing). List this across the top of a table as in this example.

Watch TV

Go to bed

Go to the cinema

Then you need to list the consequences and properties of your decision. List these on the side like this.

	Watch TV	Go to bed	Go to the cinema
Will feel rested tomorrow
Saves money
Can watch zombie land
Can eat popcorn

Each thing on the left then needs a weight, i.e. how important are they compared to each other.

	weight	Watch TV	Go to bed	Go to the cinema
Will feel rested tomorrow	2
Saves money	1
Can watch zombie land	2
Can eat popcorn	1

Now it's time to measure the effect of each option. Your default option (if you have any) should be neutral in regards to all effects so put zeros in that column. Then write down if the other options is better or not than the reference (i.e. the default option). If it's better, put a one in that box and if it's worse put minus one there. If effect is comparable to the default option put a zero.

	weight	Watch TV	Go to bed	Go to the cinema
Will feel rested tomorrow	2	0	1	-1
Saves money	1	0	0	-1
Can watch zombie land	2	0	0	1
Can eat popcorn	1	0	-1	0

Now calculate the sum for each column and remember to use the weight for each row and you should have a decision on top. In this case go to bed. So how do you feel about that decision? If you think it's good you're done but if not you should revisit the weights and also try to find more attributes to put on the left side. Or maybe even a new option. Repeat until you get a decision you're ready to make.

	weight	Watch TV	Go to bed	Go to the cinema
Will feel rested tomorrow	2	0	1	-1
Saves money	1	0	0	-1
Can watch zombie land	2	0	0	1
Can eat popcorn	1	0	-1	0
		0	1	-1

So now you have another tool to make decisions. You don't want to use this for all your decisions but it can be useful at times.

How to prevent the use of "SELECT *"

2009-11-08T16:11:00Z

One good tip for writing good SQL code is to always select the columns you need and never just select everything. Well here is a description on how to actually prevent SELECT * queries (you need to complete a free registration to see the article). The basic idea is to add a dummy column to all your tables and then limit the access to this column using DENY SELECT ON OBJECT for that column. Personally I think this is maybe taking it a little bit too far but desperate times calls for desperate measures, right...

Team Coding Dojo 7

2009-11-06T14:11:00Z

This time we did a new Kata - variant of poker hands. Instead of being so specific about the interface the user story we used for the Kata was simply; Given two five card hands I want to know which hand is the winner. We also choose to use the object calisthenics rules. The biggest benefit from not having a specified interface was that we did not have to do any string parsing and could design our interface as we wanted. That definitely felt like a kick start for an object calisthenics session. In the retrospect we also noted that in some cases it is good to bend the object calisthenics rules for the sake of progress with the Kata. Sometimes it is just not worth following the rules strictly. But each breach of the rules should be carefully considered since the purpose of the rules is to flush out changes you would normally never see.

The poker Kata is definitely an interesting one and I can see how the solution can take many different paths. Looking forward to try it again.

Refactoring is not rewriting

2009-11-05T04:55:00Z

Today I got that feeling of how the use of one word, interpreted differently by different people result in misunderstandings. It was when I read this which IMHO is full of misunderstandings (including some of the comments). One example is that refactorings must break unit tests. No that can never happen because refactoring is about changing internal structure and design without changing the functionality. What is typically a pain with a bunch of unit tests in place is when you realize your design sucks and you want to rewrite something. The border when you go from refactor to rewrite may be gray but refactorings are always small and should never change the functionality (including the API). So when I say unit tests makes it easier for me to do refactorings that says nothing about when I need rewrite/change something.

There is a valid point that having unit tests means you have to change unit tests when you need to rewrite/change something. But if you've written your unit tests and code in a good way this impact should be small. Just because you feel something makes your life harder sometimes does not mean it is wrong, it might mean you're doing it wrong. And one way to prevent yourself from having to do these cumbersome rewritings is to make sure your code is very simple and that each entity only does one thing. Something that happens almost by itself if you're doing TDD... In my experience, every time I find a solution hard to test or hard to change because the tests breaks massively with a small change, it does not mean TDD is a bad idea. It has always meant that I should solve the problem in a different way where the code is easy to test and tests are not fragile.

How do I get someWin32API method to work in .Net?

2009-11-01T21:11:00Z

It was some time since I last needed to use P/Invoke but it seems like I always need something from a standard C DLL or the Win32 API. Not that I needed it today, but I stumbled across this site which I will remember for future reference. Looks very helpful.

Definition of mocking

2009-10-29T04:40:00Z

When I read what Uncle Bob wrote today about how he usually hand-rolls his mocks it not only stirred up trouble. It also reminded me of why I hate the mock vs not mocking debate. First of all there is a clear difference in what people mean when they talk about mocking. I kind of covered it earlier but here is a recap; Either you mean you're using mock objects or you're using a mocking framework. Most often people mean the latter. And there shouldn't be a religious debate over this because most people would agree that you should always use the best tool for each task. No tool can be used for everything. Also the definition of done is pretty common in the agile world (where I think mocking is used more than outside the agile world) and if we think having a clear understanding of what done means, we should also remember to make sure we define what we're talking about before we get all excited and start argument for either side.

That said I can only say what I think (again). Mocks are powerful and can easily be used wrong (see link to my previous post above). The use of mocking frameworks also tends to make the code harder to understand, sometimes for everybody and sometimes only to people who aren't familiar with the framework syntax. That is an important point to me. Tests should always be easy to understand and to me that means hand-rolling mocks most of the time.

Five reasons to shorten your sprints

2009-10-26T17:26:00Z

I've been involved in a few discussion on iteration length lately and was going to write something about it, but it turns out I don't really have to... Since it would more or less be a repetition of this. So sorry, there will not be a list of five reasons to shorten your iterations here... But I would like to add one thing. Scrum is not a silver bullet. Scrum helps getting surfacing problems and if you think the length of the sprint makes something cumbersome you should shorten the sprint because the more it hurts, the more likely you are to address the real problem and fix it. Souse this rule of thumb (not only for sprint length): If it hurts, make it hurt some more. That way you have a good incentive to fix it.

Never convert your story points to time!

2009-10-23T17:23:00Z

When I read these observations on estimations I was reminded of a thing that happened to me a few years ago. The team I worked with started out doing story point estimates and then breaking everything down in the iteration into hours. After the first iteration the team know that X points equaled Y hours. Turned out that X=10Y. When planning the second iteration that knowledge was used to "verify the hour estimates" and sure enough it unveiled a few tasks the team had forgotten during planning. So it all looked like a great way for the team to make sure they didn't miss some important part when breaking down user stories into tasks during sprint planning. At the time for iteration three the story points were no longer used because the team felt it was just an annoying double bookkeeping and everybody knew that one point was ten hours anyway. From that day forward the team consistently under estimated their work. This team did not have the time to establish a track record as the team described in the link above but they also never had a chance I think. Estimating software development in time is very hard and the amount of time you spend on making the estimates does not necessarily improve the estimate with the same factor. Add to that what I wrote earlier this week indicating that the size is more or less useless and only the number of things are important.

But in the defense of time estimates, it is not really the time that is the problem, it is the lack of learning from the past and using historical data to predict the future. I was personally once part of a project involving around 20 developers for one year. Turned out the amount of work it took to complete that project was one man-month less than the initial estimate (i.e. less than 0.5% over estimated). The reason for this? The project manager and key developers had developed virtually the same application for another customer a few years earlier... But that is in my opinion a very expensive way to do estimates so I prefer spending as little time as possible on actually estimating things and more time on understanding the user stories and completing them.

How many t-shirts in your next iteration?

2009-10-21T17:21:00Z

So considering my last post on t-shirt sizes and burn-downs, how do you decide on how many t-shirts to take on in the next iteration? If you assign some value to each size I guess it is easy since you have your velocity to use. But I heard another interesting thing from a guy I worked with the other day. He had been on a team where they did not assign any number to their t-shirt sizes. They just expressed their velocity in terms of how many user stories of each size they could make in each iteration. For example they might have had a velocity of "2L, 1M, 1S" meaning that in each iteration they tried to complete two large, one medium and one small task. I like this idea since it is simple. And easy to adjust. When you realize you don't have that many large user stories left but a bunch of medium ones, just try a new mix and adjust until you know your new velocity (which might be 1L, 3M, 2S).

How to burn down estimates in t-shirt sizes

2009-10-20T04:09:00Z

Some people estimate their user stories is t-shirt sizes, i.e. each story is either small, medium or large. But how do you create a burn-down chart for these estimates in order to estimate when you will be done? I guess a very common way is to assign some kind of number to each size. But what number? I know that one person used 1-2-3 (i.e.S=1, M=2, L=3). Let's assume that you are completing tasks in more or less random order, and random size (but more big tasks than small tasks) then the burn-down might look like this after 10 iterations.

From this burn-down we can see that we will need slightly less than 21 iterations to complete all user stories if the trend is correct. But what if the size difference is wrong? What if a medium is three times as big as a small user story and large is five times the size of a small story?

This is the same question another Microsoft developer got when showing some co-workers how burn-downs could be used to estimate project completion. So this person took the actual data he had and changed the values to 1-3-5. Interestingly enough the result was almost the same. I did the same thing on my random data and the estimated number of iterations needed is about the same as you can see here.

So this made that developer think... Maybe the values representing t-shirt sizes does not matter all that much so he gave all sizes the same value; one. I.e. the burn-down basically represented the number of remaining user stories. Funny enough it turned out that the estimated number of iterations needed to complete them all was again very close the the first estimate. Using my random data you can see that it would take exactly 21 iterations to complete all user stories.

Back to that developer that inspired me to write this. He finished the project and it turns out that the actual number of iterations needed to complete all stories was also very close to all estimates made when half the stories were completed. If I remember correctly they turned out be all be within 5% of the final number. And being 5% wrong on estimates is way better than most people I know when trying to estimate in hours, days or weeks instead of looking at the velocity of the team.

Since I had the data I could not resist making a few more tweaks to the graph. Not surprisingly using 1-2-4 is very similar to 1-2-3. Same for using preferred numbers (my data using start of R5 series (1-1.6-2.5)). Made me think... What about values in totally different ballparks so I used 1-10-100 (i.e. Large being 100 times bigger than a small task). Interestingly enough the estimated number of iterations turned out to be slightly less than 20 in the burn-down. And reversing the values (using 5-3-1, i.e. small is biggest task) gives us an estimate of just over 22 iterations.

So is it safe to draw the conclusion that size of tasks does not really matter in your burn-downs? Is it safe to say that the number of user stories is enough? In my opinion; yes. Yes in theory you may complete only big or small tasks in the beginning saving the other type for last which would make your early estimates wrong if you do not take size in to account. But I don't think teams typically work in this way. There will be a mix of small and big tasks in each iteration. I would compare this to quick-sort. Quick-sort is pretty bad for the worst case scenario but pretty decent on average. I would say the same goes for using burn-downs where you ignore the size of user stories. And the benefit is that you do not have to spend time doing estimates. Just focus on completing those user stories delivering value to your customer because having no sizes is probably good enough.

Software development at the fish market

2009-10-12T08:40:00Z

The Fish market at Pike place is famous for its flying fish. I was there this weekend for the second time in a few weeks (benefit from having friends and family visiting from Sweden). But it is not the flying fish that make the show interesting I think. It is how the crew is shouting all orders out and get it repeated by the rest of the crew. Most people watching probably just think it is a funny detail in the show. Some might know that it started as a prank only. But what it really is is a great way of making sure everybody involved (the employees) know what the order is and what is going to happen; i.e. what fish will be thrown where. Made me think again about one of my old comparisons between software development and the military. The same thing is used in the army to make sure orders (and important information) are heard by everybody. The fact that an order is repeated is also not only good to make the order heard by everybody, it is also an acknowledgment of that the order has been heard. So when the order maker hears the order repeated he knows it have been heard.

So what about the title; software development at the fish market? Well actually nothing more than I think people in the software business repeat things much too rarely. Not only small things that can be quickly repeated but all kinds of feedback and instructions benefit from being repeated. Think about it. Each time you ask somebody to help you with something, does it turn out as you expected? Probably not. And you either think the other person is stupid or you blame yourself for being unclear. In my experience people are not stupid in general. It is you who are being unclear because the other person has a different set of reference points to what you want them to do. The best thing to make sure somebody understands what you mean is to ask them to repeat,in their own words, what you just said. But don't forget to do the same thing when somebody asks you to do something...

Creative solutions for remote team members

2009-10-07T18:00:00Z

I'm always amazed when I hear how teams make remote team members being co-located with everybody else. But rolling a laptop around on a small cart is definitely the best I've heard about so far...

Coding Dojo 6

2009-10-06T08:05:00Z

It was MineSweeper for the 6th MSFTCorpDojo today. We also applied the object calisthenics rules this time. We ended up with a lot of interesting discussions on how to design to follow the calisthenics rules and this lead us to not really driving the design using tests but rather to create tests following the design. In my opinion it was also unsatisfying that we only implemented the small building blocks we thought we needed and almost no part of the algorithm needed to solve the problem. After using object calisthenics a few times it feels like it leads to interesting design discussions at the expense of the basic TDD experience. It'll be interesting to see if we'll be able to get both in the next session.

Adding days to an iteration (sprint)

2009-10-04T06:41:00Z

In Scrum you never extend a sprint. Read that again. Never. So why do some teams extend their sprint a few days sometimes?

I think the most common reason is there is some functionality that is almost done and it feels better delivering "in a few days" rather than "at end of next sprint". Might even be so that there is a dependency or hard date deadline that needs to be met. I think this usually is an invalid argument. I don't think Scrum says you're forbidden to deliver things to the customer in the middle of sprints. If you really need/want to deliver before the end of the next sprint, do the planning so that you deliver something after a few days in the new sprint instead of extending the sprint.

Another reason I've seen is that the team have miscalculated the number of working days they could have anticipated (holidays, team events) and some they couldn't anticipate (power outages). The reasoning here is that "planning was for X days and since we missed Y we should extend Y working days". At first glance I think this looks OK. The team is just trying to keep the sprint length consistent. But if you look deeper I think this is also wrong. The team is not looking at the root cause and learning from the failure (i.e. make sure to take holidays and team events into account). Also this is no different than if there is a flu going so that most of the team is sick a few days during a sprint.

Changing the end date for a sprint also introduces another problem. What the team has planned outside work. Personally I tend to plan things like dentist appointments and other meetings during the sprints since I'm more flexible during the sprint. It is my choice if I have to go out for a few hours during the day and I can decide myself to make up for that time in the morning or evening. But between sprints my working day is not that flexible since it typically involves a number of planning and retrospective meetings. Even when I have several days between sprints they tend to fill up quickly with all sorts of meetings. So when the end date changes it is a high probability that some plans I've made for the beginning of the next sprint need to be changed too since it is now in a day between sprints.

So what if there is nothing outside work that needs to be rescheduled and adding another day to the sprint means the ability to deliver something much wanted to the customer. Isn't it worth it? Once? I think you should be pragmatic but in this case I think there are more pedagogic ways to handle this. Handle it as the failure it is, analyzing what went wrong and come up with a plan on how to avoid it next time. Then then take one or two days just focusing on the thing that is so much wanted. This way you are less likely to just accept and forget the failure just because everyone agreed it was a good idea to extend the sprint. And if you find yourself often in this situation, sprints may not be suitable for you. Something like Kanban might be more appropriate for you.

Exceptions or not?

2009-10-02T08:01:00Z

I've always had mixed feelings for exceptions. First of all exceptions should only be used for exceptional things, not things that are expected. For example if you open a file it may fail for several reasons; it does not exists, you do not have rights to open it or it may be locked. These are all perfectly reasonable errors and throwing an exception for these failures is in my opinion not a great API design. If there are other methods to check for all these circumstances it might be OK but not optimal. A reasonable compromise is to have a TryOpen method which never throws an exception. This gives the user of the API the option of letting file open errors being expected or fatal.

Because exceptions should only be thrown for exceptional circumstances there should be no reason to catch them other in the application's main loop unless you can add information to the error in which case you want to wrap and throw a better exception. The exception to this rule is when you use an API (such as file open mentioned before) that throws for pretty common error cases you want to ignore.

Another thing I don't like with exceptions is the fact that you (in C++ and C#, Java is better here) get no help from the compiler to know what types of exceptions a function may call. So in C++ and C# you may think you catch everything you need but you really don't which leads to unwanted behavior in your application. It is just too easy to get into a situation where you think a number of lines are going to be executed but they're not for some exception.

However if you use return codes (as you would in a C program) you get your code cluttered with "if (previous called failed) handle error" which hides what the code really does. This can be hidden using macros to handle errors (ex: result = DoSomething ON_FAIL_RETURN(result); ). And if there is no error handling it is hard to know what happens when the next line is executed even though there was an error.

Using exceptions is also a kind of "I failed and I hope somebody else somewhere can handle it" while the use of return codes defines a clear contract "I failed and you who called me must handle it". So even though exceptions are convenient, return codes feel more defensive, i.e. are easier to get right resulting in less bugs but sometimes at the cost of less clear code. As usual the mix of both approaches is probably the best. But there are more alternatives. If you use adverse as described by Feathers I'm prepared to accept exceptions to a much larger degree because they're being handled immediately so it reminds of the return code approach.