Being Cellfish

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

June, 2010

Change of Address
This blog has moved to blog.cellfish.se.
Posts
  • Being Cellfish

    Viking laws

    • 1 Comments

    After reading this which jokingly tells us that the Viking laws will replace the agile manifesto I started to think about manifestos and "agile". The agile manifesto well describes how you need a change in your mindset to become agile. And some try to refine it even further. But the Viking laws are brilliant. And I find it intriguing how they describe the right mind set for an agile software developer. Reminds me of my own observations on similarities with the military. Let me elaborate a little on the Viking laws and how I interpret them into a software development context.

    • §1 Be brave and aggressive.
      • Be direct.
        Do not protect others from the truth, speak clearly on your thoughts. Same applies to your code; it should be clear and simple.
      • Grab all opportunities.
        Do not be afraid to take on new challenges.
      • Use varying methods of attack.
        Explore different ways to solve a problem. Do not do the same thing all the time.
      • Be versatile and agile.
        Be skilled in many different areas and use what is best for the task at hand
      • Attack one target at a time.
        Focus on one thing and complete it before starting the next, for example only one user story at a time.
      • Don't plan everything in detail.
        Things that are imminent may need more planning than things in the future. Don't plan more than you're prepared to throw away when things change and your plan becomes invalid.
      • Use top quality weapons.
        Use the best tools available.
    • §2 Be prepared.
      • Keep weapons in good condition.
        Your tools should be updated and working properly.
      • Keep in shape.
        Sometimes you need to practice things on your own that are not in your day to day work.
      • Find good battle comrades.
        A good team can perform great even under chaotic circumstances while a bad team will always fail. You want to work with great people that share your values for most of the time at least.
      • Agree on important points.
        Don't spend energy on convincing everybody of something that is not important, but make sure you all agree on the important things.
      • Choose one chief.
        For those hard decisions that the group cannot agree on, rely on a single person (who you all respect) to make an informed decision for the team.
    • §3 Be a good merchant.
      • Find out what the market needs.
        Don't do things the market does not want.
      • Don't promises what you can't keep.
        People like pleasant surprises, not bad news. Only promise what you can do and there is one promise you always can give; "I'll do my best".
      • Don't demand overpayment.
        Just because you're the only person in the world who can do something you should not demand unreasonable compensation for what you do. That is not the way to build long lasting relationships.
      • Arrange things so that you can return.
        Whenever you leave a team or complete a section of code, make sure that you are welcome to return.
    • §4 Keep the camp in order.
      • Keep things tidy and organized.
        Backlogs, code, documentation etc should be tidy and organized.
      • Arrange enjoyable activities which strengthen the group.
        A happy team performs better than an unhappy team. Do fun things together!
      • Make sure everybody does useful work.
        Everybody needs to feel that what they're doing is useful and drives the team forward.
      • Consult all members of the group for advice.
        You should not revert to democracy for all your decisions but you want to make informed decisions so consult all members of the group. Even the less experienced team members may have an important point of view you need to consider.
  • Being Cellfish

    MSTest does not call all tests in a class before moving on the the next test class

    • 1 Comments

    I recently heard of somebody who moved away from using MSTest and started to use NUnit because NUnit called the class setup method, then all tests and last the class tear-down before moving on to the next test class while MSTest more or less interleaved everything. I'm not a big fan of MSTest so I'm absolutely not defending MSTest but I think the team that made this decision moved to NUnit for the wrong reason. First of all I want to make it clear that the problem was not with a set of unit tests, it was with an integration test suite that was implemented using a unit test framework. And being an integration test it neaded to setup a lot of things so it wanted to do the setup only once for each test class (i.e. suite). The problem was that several suites worked on the same data and hence could not run concurrently. I think that was the real problem. Each test fixture, regardless of if it is setup for a single test or a test suite must be isolated in it's context. This means that if you setup a database you should have different suites working on different parts of the data so that they can coexist. This is a good idea to avoid weird test failures because a cleanup method is not correctly implemented. If you're testing a network service you need to start it using different entry points (i.e. listening to different network ports) so that they don't interfere with other services being tested at the same time. Because if you design your tests in that way you will not be limited by the framework, it will just be a tool for you and you can change the tool more easily if you need for another more valid reason.

  • Being Cellfish

    Why have iterations?

    • 0 Comments

    Almost two months ago Michael Feathers wrote a thing on zero length iterations. The post is very similar to the one that inspired me to write this but he also brings up an important point; the intention of iterations is to force a decision, force the team to make trade-offs and keep moving towards a goal. That is exactly what military decision making is all about; keep the initiative by making sure you make a decision that is as informed as possible before it is too late. I guess that is yet another example of things software developers can learn from the military.

  • Being Cellfish

    What to do when one user story is complete and all other user stories are on track

    • 0 Comments

    There was recently a discussion on an internal distribution list that caught my eye. The initial question was; when should you add more to a sprint instead of ending early? At first glance I think it is safe to assume that while the person asking the question claimed to be doing scrum he had missed a few points. One being; you keep the sprint length for a very long time. IMHO there is no ending sprint earlyin scrum. You keep your sprint length fixed since you want to measure the number of user stories (or story points) the team can complete in one sprint to make a release plan and estimate what will get into a certain release. So far I don't think there was a lot of discussion to happen but the question had some more information that made the question more interesting. Turned out that the team consisted of 8 people and they planned 4 user stories in the sprint. This meant two people was working on each user story for the duration of the sprint. And the question was more about what to do when one user story was completed. Do you bring in a 5th user story or do something else?

    Basically there are two options; Either you bring in a 5th user story or you have the "free pair" helping the rest completing the planned user stories. This is when it gets really interesting since I don't think there is a simple answer. Or actually there are two simple answers; It depends and you decide. The important thing is that the teammakes the decision and that they make an informed decision. There are also a few traps an inexperienced team (i.e. a team learning Scrum) can walk into so the Scrum Master may want to prevent the team from making some decisions in some situations. These are a few things the team and Scrum master should consider:

    • By  bringing in a 5th user story you may end up with a situation where not all 4 planned user stories are completed but instead one or two bonus stories are implemented by the end of the sprint. This can be both good and bad:
      • If you're actually releasing things after each sprint and/or you have communicated that certain things are going to be completed the customer may be unhappy if they get only 3 of 4 planned user stories even if 2 bonus stories are completed.
      • If you do not release after each sprint and/or the customer cares more about total amount of work completed rather than exactly when different things are delivered it may be good to deliver 3 planned and 2 unplanned things over 4 planned since 5 is better than 4.
    • Having the team focus on the planned things first gives them an opportunity to learn more areas. A common objection to having more people on one thing is that it is inefficient. It is important to remember that you should not throw more people at a problem if it does not a good investment. You don't want to slow the original developers down but IMO people are way to fast in saying "I can't split this work up more". Just sitting next to somebody working may be a goodlong term investment for the team. And if the team is forced to work on fewer user stories they will come up with ways to split the work and work efficiently. That is a good investment for the future when you do want a lot of people working on the same thing sine it is a very important user story.
    • When people say they're on track they either mean they don't know if they're late or not or they're lying. You cannot know that you're on track until you're done. That's the nature of being agile I think. But agile is also about managing risk. i think it is too early to even consider more user stories when only 25% of the planned user stories are completed but when 75% of the user stories are completed and 75% of the team is free for new work you may want to add a few to the remaining 25% planed and then use part of the team to look at bonus user stories.

    In my opinion the situation described in the question is wrong from the start. Starting all 4 user stories at once and having pairs more or less working in silos on "their" user story for the duration of the sprint does not sound agile to me. It sounds like old fashioned silo/code ownership practice that is a bad investment for the future of the team. I think the majority of the team should swarm on the most important user story and then a few can start on the second most important one. By working on all 4 at once the team is risking to complete none. Top priority is to complete at least one user story, then two and so on.

  • Being Cellfish

    I need a shorter sleep in order to move my snake faster

    • 0 Comments

    i got an email a while ago from somebody who had read this. The person was trying to implement a snake game and the question was about sleep times since the person used sleep to define difficulty levels. The higher level, the faster the snake should move. the problem was that he used a small sleep in a very tight loop and the snake did not really move any faster once you completed a few levels. He experimented and figured out that the sleep always slept between 10 and 15 milliseconds even though he tried to do a sleep for just 5 milliseconds. The problem was that he forgot this fact; Sleep does not sleep for a specified time. And interestingly enough; on Windows the resolution of a sleep call is between 10 and 15 milliseconds.

    So how do you solve this problem? Since we're talking about a game we can safely assume it will be played by humans. And the human eye/brain combination can be happy with as low as 30 updates per second, but 60 should be a safe bet under most circumstances. Hence updating the snake position more often than 60 times per second (note that a sleep of 15 milliseconds gives you 66.666... updates per second) is not really necessary. So in order to move the snake faster at higher levels, all you need to do is to move it further each time you move it but always move it at the same interval.

  • Being Cellfish

    Time to change to a new team

    • 0 Comments

    Today was my last day on the System Center Cross Platform team. On Monday I'll be working on the Robotics team.

Page 1 of 1 (6 items)