Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

October, 2008

Change of Address
This blog has moved to
  • Being Cellfish

    C++ pointer basics for kids


    A little video to explain pointer basics in C++ to your kids... If you for some weird reason want to do that...

  • Being Cellfish

    Beginners should not use LINQ


    When I first heard of LINQ I got really scared. I could see that it was a very powerful tool but also a tool that would be easy to abuse. Most experienced developers tend to agree that putting SQL statements into your logic or even GUI code is a bad design. Beginners tend to realize this pretty soon too. But with LINQ we get the opportunity to do the same kind of bad design once again. And since it is ".Net code" rather than "SQL statement" I had a fear that it would take longer before the beginners learned their lesson. And why do I care? I don't know. Guess I'm just one of those guys who want everybody to do a good job.

    Since LINQ was introduced I have not really seen LINQ in action very in any real code so I kind of forgot about this. But then I read this. Looks like I was right. LINQ is being abused just in the way I feared. But I'm happy to see that a person who I've heard speak warmly about LINQ so many times finally points out how LINQ can be your gate to bad design. And remember to read the comments too when you follow the link above. The topic unfolds...

    UPDATE: Not only did the topic unfold in the linked thread. It unfolded here. If you just found this page I strongly suggest you read all the comments.

  • Being Cellfish

    Xbox Fit


    You will probably never see an Xbox Fit because Microsoft would never get away with things like Nintendo does with the Wii Fit. You have maybe seen this comic before and if you don't own a  Wii Fit you may just laugh at it. But there is a lot of truth in that comic. I know because I own a Wii Fit. Let me tell you what I've experienced...

    Sometimes (about once every month) I get a question when I start Wii Fit: Have you noticed anything about X's body recently? "X" is the name of my wife who also uses the Wii Fit. And I have to choose one of four answers: "No change", "Gained weight", "Loosed weight", "Better posture". This is a loose-loose situation for me. Because if I answer "no change" or otherwise wrong I'll get a "maybe you're not paying attention to X". If I choose the "correct" response the Wii will tell me: "you should say that directly to X". So either way, regardless of my answer, the Wii Fit will make me feel guilty...

    My wife get another kind of questions... I tend to use the Wii Fit pretty late in the evening and then play some games. When that happens it gets close to (if not passed) midnight before I turn the Wii off and go to bed. In the morning (around 6am) I get on my Wii Fit to get the daily weight. I do this in the morning because it kept telling me, doing the fitness test at different times each day makes them less accurate. So I do it in the morning. Somehow it checks my user profile and sees that I was up late so it pretends it's sleepy. And then my wife get messages like: "You should tell Y to sleep more". Y being my name.

    Think about that for a moment... The game uses my profile to harass me and my family about my sleeping habits... The intention is good but isn't this an invasion of privacy? Now think what would happen if Microsoft released a product that tracked your habits and started to tell you (and your loved ones) that you should change... That's why I think we'll never see Xbox Fit.

    Talking about the Wii. There are however a few other cool things you can do with the Wii that I'd love to see on the Xbox too...

  • Being Cellfish

    Exit Mocks. Enter Stubs!


    Since I'm not a fan of mocks I guess my prayers have been heard. Microsoft Research will soon release a stub framework. That's right. Stubs and not mocks! It is part of Pex that I have mentioned before. And you don't need to use Pex if you don't want. You can just use the stub framework by it self.

    The new stub framework can currently be used to stub interfaces. It creates the stubs by generating code. At first this scared me since I feared it would not regenerate the stubs when the interface changed (which might happen quite common when creating the interface using BDD). But it works just fine and detects changes in the assembly and regenerates the stubs. Very convenient.

    Another convenient thing is that it supplies default implementations for methods if I want. The default is to throw an StubNotImplementedException but I can change that and return default values (null, 0, empty string etc) if that is what I want. And the change can be made globally for all stubs created after the change or for a single stub object.

    So how does this work? Consider the following interface:

    public interface IMyInterface
        int DoStuff();

    I just tell the stub framework to generate stubs for the assembly containing the interface and it will generate a new namespace with the stubs. If IMyInterface is part of MyNamespace the stub framework will create a new namespace MyNamespace.Stubs with a class SMyInterface. Now we want to make a test. The test below doesn't really make since since it tests the stub instead of something using the stub, but I want to show the code that makes the stub work without the surrounding stuff so bare with me...

    void TestStub()
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());

    Now the test will fail since the stub will throw an exception since the stub is not implemented. Let's use the default implementation:

    void TestStub()
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());

    Still a failure since the stub returns zero for DoStuff(). Let's stub that method.

    void TestStub()
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
        o.DoStuff = (stub) => { return 42; };
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());

    Now the test passes! I think this new framework is an excellent addition to the developer's toolbox. And I think it is a better starting framework than all the mock frameworks out there. In the few cases that a mock framework is really needed (over a stub framework) you can easily extend your stub to verify behavior in the same way as a mock does. Currently the stub framework have a few limitations such as only being able stub interfaces. But I'll guess we'll have to wait and see what will be part of the release once it is available to the public (when writing this I've been using an internal release available to Microsoft staff only).

  • Being Cellfish

    The army is agile!


    Up until recently I was a platoon commander in the Swedish national guard. Since all peace time activities in the Swedish national guard are based on work done voluntarily I applied a number of agile principles when running the platoon. I used a task board to visualize all activities needed to plan future exercises.  I had at least monthly meetings with all squad leaders to keep us all updated. At these meetings we also discussed how the platoon activities could be improved and planned for the next few weeks. So we definitely used the concepts of retrospects and task board. Not very militaristic but when working with volunteer weekend warriors I think it worked out pretty well.

    The Swedish armed forces enforces mission type tactics. This leadership philosophy was used successfully by the Germans during the second world war  and have since been used in most special forces units. The basic concept is that each commander gives his subordinates the mandate to solve a task given the best way they see fit. The commander must also make sure the subordinates have enough resources to complete any task given. This sounds very agile to me. Maybe not what you expect an organization that is extremely hierarchical.

    This made me think that there are maybe more military situations where we can see typical agile properties. And maybe even we can learn from the military to improve how we develop software in an agile way. The first thing I thought of was combat. Military combat means chaos. Agile software development is a try to control the chaos of software development. When I look at how I have prepared my previous platoon for and then engaged in combat have a lot of resemblance with how agile development projects are (or should be) run.


    Almost all projects start with some kind of planning and so does military combat. There is also a military saying: "No battle plan survives the first shot fired". So how do I create a good battle plan for a platoon? Well, the bottom line is to provide as much information as I can about the situation and what I want to happen but without being too detailed. The first thing to do is to gather the platoon. The best plan is one heard by everybody and not just the squad leaders since when squad leaders tell their squad some information may be lost or accidentally changed. Once the platoon is gathered I start with giving them information about what's known about the enemy and what's known about other friendly forces. I also tell them what the task of the company is and what's our platoon's task.

    When the situation is known I tell the platoon what the goal is. If our task is to assault a hill, I tell them where our squads should end up when the assault is completed. This is very important since during combat it will sometimes be hard to get all the needed orders out to each squad. But since everybody knowns what the goal is everybody can work toward that goal without explicit orders.

    After I have told the platoon what our goal is I give quick overview of how I plan to get to the goal. Still without being specific. If there are any situations I can predict I would also tell the platoon what these are and how we should handle them by default.

    Example: If we're ambushed from the right. The default action is to suppress with engaged squads and outflank with Hotel-Alpha (Hotel-Alpha being the call-sign of one of the squads).


    Now that everybody knows the big picture, our goal and my intentions on how to get there it is time for orders. Exactly how these orders look like obviously depend on the situation. But I have always tried to give an order for what the squad leader can see. And one prepared order. A prepared order is most often what I intend for the squad to do once the order is executed but it can also be a reaction to one of the predicted alternatives we have. Example: Hotel-Alpha, advance as last squad toward target. Be prepared to outflank.

    The reason to give an order which only includes one thing that the squad leader can see and one (or maybe two) prepared order is that I want leave as little room as possible for misinterpretation and not force the squad leader to think to much about what comes next. Also if something happens and the orders must be changed my experience is that no orders but a clear goal is better than a lot of orders with a clear goal because people tend to stick to the orders if they still apply.

    A little comparison: The goal is to advance to and cross a road and then assault a house. Think about these two alternatives (where everybody knows we are to assault the house):

    1. Advance to the road and cross it. Be prepared to assault the house.
    2. Advance to the road. Be prepared to cross the road.

    The second alternative (B) is much easier to do right. Also we don't know what will happen at the road.

    Also the order includes important information like where wounded soldiers should be transported, where we should retreat to if the enemy turns out to be too strong and where the platoon commander will be during the assault.

    Finally every order is ended with me asking each squad leader and then the platoon if there are any questions. Questions are answered and then each squad commander is asked to repeat his orders. This way I know they know what to do. Even with simple orders you'll be surprised how much can be misunderstood. Especially if you start trying to give orders for several steps of the assault.


    So, no battle plan survives the first shot fired. So what do we do to control the chaos of a combat? Information is important. Observations by individual soldiers are shouted and repeated by all others so everybody knows what's happening and can adapt to the evolving situation. The same applies to orders and information from the commander. Also the goal (given previously during the order phase) helps pushing everybody in the right direction. Another important thing to win a fire fight is keeping the initiative. It is always better to act then react. Doing something is better than doing nothing.


    So now we've won the battle and achieved our goal. What do we do now? The first thing that typically happens is that the squad leader gathers information from the squad regarding ammunition and injuries. This information is transformed into a summary to the platoon commander indicating what resources are needed (if any) in order to proceed.

    Comparing with software development

    I'd like to compare a military assault with an iteration. Giving the team the overall goal as well as the iteration goal will help the developers make the right decisions during the iteration.

    If we compare the military order with the user stories in the iteration I think we can still learn something from the military. We should only have user stories the team can understand immediately (i.e. "see") and we should keep the number of options (prepared orders) to a minimum. Also make sure that important information such as where the product owner will be during the iteration is available to the team from the beginning of the iteration.

     In the day to day work ("combat") it is important that everybody knows what's happening. Especially when something important happens I think the team would benefit from adopting the military way of shouting out critical events and having everybody repeating them.


    Military Software development
    Reloading! Installing new version on test server!
    Enemy to the left! Broken build!

    There is no way anybody in the team would miss something if everybody shouted stuff like that out.

    When the iteration is over we should naturally have a retrospect but there is one thing we can learn from the military. That is how we present the result of the retrospect. If the suggested improvements from the team are presented in terms of  "what we need to complete the next iteration" I think it is more likely to be taken seriously than if it's just "we want to do this since it will be better". Also it focuses on what's needed to improve the process now. Stuff that will improve the process later can also be handled later.

  • Being Cellfish

    Should you track completed effort for your tasks?


    Many (agile) projects uses a burn down chart to track remaining time. It is a commonly used visualization "tool" for progress. But there are also teams that keep track of completed time for each task. Typically they do this in order to see how the completed time corresponds to the initial estimate. using this information the team hopes to improve their ability to estimate things correctly.

    So even though the purpose is often the same, the reason is often one of two things. If the team is lucky it was the team that decided to track completed effort because the team believed this was the best way to improve the team's estimation skills. On the other hand I think a much more common scenario is that management want the team to track completed effort because they want to know how good the team is at estimating and management thinks that tracking completed effort will help the team improve estimation skills.

    In the past I've had no problem when the team decides to track completed effort since it is a team decision. But when it is enforced by management all kinds of alarms are triggered in my head and I do my best to prevent it. I guess this is how many people see this and many other things. As long as it is a team decision to do something it is alright. The team will stop doing it if it turned out to be a bad idea.

    So if you're working as an agile coach and the team comes up with the idea of tracking completed effort in order to gather data and improve their estimation skills, should you encourage them to do so? Up until recently I would have said yes every time. But now I've changed my mind since I recently was involved in a discussion regarding this and I was presented with an argument that made me change my mind completely. take a look at the following burn down chart.

    Example burndowns 

    The chart consists of an iteration with 20 working days. The team starts the iteration with the assumption it will complete 20 story points (or what ever you want to call them). So in essence they believe they will complete one story point per day. So if the team is making correct estimations they will complete just that and there is no need to track completed effort since the estimate is correct.

    Now look at the green (over estimate) line. The team have over estimated the effort and completes 20 story points in just 14 days. This means their velocity is not 1 story point per day but rather 1,43 story points per day. So they have over estimated every thing by approximately 40%. Without having to look at each task we can see that the estimates should be reduced by 40% if we want to do 20 story points each day.

    Looking at the red (under estimating) line we see that the team completed 14 story points in 20 days giving us a velocity of 0,7 story points per day. Adjusting the estimates means we have to add 40% to each existing estimate if the goal is to do 20 story points in each iteration.

    When using story points you don't typically change the estimates - you change the velocity for the next iteration. But I think this example shows that tracking completed effort is not really needed if you want to improve estimation skills. Some estimations will always be higher and some lower. And looking at the totals there is no need to track completed effort since the total completed effort is a known value. It is the length of the iteration. Using this technique you'll probably have enough data to improve without adding the overhead of tracking completed effort or risking the team thinking tracking completed effort is just a way of tracking who does a good job and who doesn't.

    So now for the advanced part of this dilemma. I still think there is one situation where tracking completed effort may be of value. First of all it must be a team decision. Second, it must be a team decision. And third, the purpose is to identify tasks that grow extremely much in order to evaluate the reason for such growth during the retrospect. The team might even be good at estimating on average, but they have a feeling (or just know) that some things are extremely over- and/or under estimated. And the team wants to make sure they identify these tasks in order to discuss them specifically during the retrospect. But the team must remember the purpose here. The completed effort does not need to be very accurate. Just accurate enough to identify the extremes. And in order to do that I don't think the team have to track effort on every task.

  • Being Cellfish

    Scrum Gathering Stockholm 2008 - Day 1


    So the first day of Scrum Gathering has come to an end. I just wanted to check in with a few first impressions. The opening session with Jeff Sutherland did not only cover the announced topic; Secret Sauce for Making Scrums Hyperactive. He also talked quite a lot on a Distributed Scrum, a topic that is very popular at the moment. Guess it has to do with companies trying to actually profit from outsourcing by using Scrum. Ken Schwaber talked on what the Scrum Alliance is doing to support Scrum practitioners around the world.

    When it came the breakout sessions I chose topics that was of interest to me and held by speakers that I didn't know much about or had never heard before. The reason for this is that in my experience the well known speakers often say more or less the same thing in a new package so by choosing a less known speaker I gamble a little in the hope of learning something new. And even in the less interesting sessions I learned at least something.

    First breakout sessions was Agile Transformation: what to do with managers. It was interesting to hear how others work to involve the middle managers in the change toward an agile organization and how to handle the fears these managers typically have. Following that session I attended The Day After Retrospective. Retrospectives being one of my favorite topics it was very interesting to hear a few new views on retrospectives and how to handle situations where the Scrum Master turns out to be the actual problem. The last session for the day was a reserve alternative since the session I intended to attend got canceled. So the last session was Does Scrum Stifle Creative Innovation. Wish I had chosen something else. It was not at all about what the title said (which actually is an interesting topic). Instead it was a lot of talk about how to survive and adapt when the product owner is doing a really bad job and not understanding what he is supposed to do; order the product backlog from a user experience perspective. So far that is OK, but I got a feeling the speaker did not recognize this as a major problem at all. To him it was normal since nobody can know everything.

    So that was a short summary of the first day.

  • Being Cellfish

    Scrum Gathering Stockholm - Day 3


    The day started with Ken Schwaber talking on the topic: It is not Scrum if... Basically he tried to correct a number of common misunderstandings from his books. I then attended a breakout session on retrospect concepts. It was nothing new but a few things I've seen very common in retrospects where taken up as examples on not so good retrospect routines. Last for the day was a Q&A session with Ken & Jeff. They answered a number of questions and there where a few interesting things mentioned that I hadn't thought about before.

    After the last session I was engaged in a very interesting discussion with Arto Eskelinen from Reaktor Innovations. Soon two of his colleagues turned up as did a friend of mine and we all had a very interesting discussion on how to implement Scrum in large organizations. The most funny thing was that one of Arto's recommendations was actually a thing I've thought of the last few days as something we needed in our project. Since Lasse Koskela was one of the colleagues that joined us (the other one was Jukka Lindström) I took the opportunity to talk a little about TDD and why I don't like mocks.

    So this means the conference has come to an end. I have not only learned a lot and gotten to see some things from a new viewing point. I've also had fun in the progress and I've got boosted with a lot new energy and inspiration.

  • Being Cellfish

    Using Project Euler to learn BDD.


    Using coding katas is a good way to learn and fine tune TDD/BDD skills. A common way to perform the code katas is in a coding dojo. But a coding dojo involves a lot of people and doing katas on your own might feel a little bit boring. At least I think doing katas alone is boring. So recently I tried out Project Euler. Project Euler is a site where you solve different more or less difficult problems and you solve them any way you like. I've started solving the problems using BDD style specs with the framework. Even though most problems are mathematical in nature I think it is a fun alternative to doing code katas on your own. And you get a chance to dust off a few of the mathematical skills from school that you thought you'd never need again.

    If you have a Project Euler account and is logged in you can use this link to view my stats.

  • Being Cellfish

    Positive reports


    Military combat is not the only  military concept where software development can learn. One thing we used in my unit was "positive reporting". Positive reporting means that we should report in to our commander often and not only when things go wrong. This helps the commander knowing what's happening.

    The positive report concept also includes adding suggestions on what can be done. This is important since the commander is typically not there and is not able to see all opportunities the terrain and situation offers.

    Bad example: Hotel-Alpha at check-point 42.
    Good example: Hotel-Alpha at check-point 42. We have clear view of check-point 4711 and I think we can take it without support.

    In software development we can benefit from using the concept of positive reporting. The first part, keeping the "commander" (product owner) updated can be done with daily scrums, burn-downs, task board etc. Things we typically do. The second part however is one thing many software developers don't do very well. Instead of just bringing problems to the surface, take a few moments and try to think of a way to solve the problem (as in combat acting is better than reacting). Even though the suggested solution may not be the best one, it will quickly get you back toward the goal. And the suggestion it self will trigger others to think of better ways to solve the problem.

Page 1 of 2 (14 items) 12