Being Cellfish

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

April, 2009

Change of Address
This blog has moved to
  • Being Cellfish

    Merging coverage reports with Bullseye


    I've previously recommended Bullseye. And there is another nifty feature with Bullseye you should know; the ability to merge reports. This is pretty useful when you have one report from your unit tests and one from some other type of test run. Use this command to merge reports with Bullseye:

    covmerge.exe -c -fMergedData.cov file1.cov file2.cov
  • Being Cellfish

    Team Coding Dojo 1


    Today we had our first coding dojo in our team. We did the MineSweeper kata and once again the dojo ended up doing the same thing as usual; got to focused on the end to end tests and string parsing. During the retrospect we concluded that event though we had a short design session in the beginning we didn't really use that design for anything else than naming conventions. We also recognized that the first test written kinds of sets the key for the session. If the first test is testing end to end, then it is easy to continue on that path since you need a second test to refine the design. Instead a better approach is probably to pick some part from the design and start testing that. The school book BDD with outside in demands faking things underneath and if you don't do that you should probably not start outside in - you should to it the classical TDD way; create building blocks as needed - inside out. Or my favorite; middle out...

    But all in all (as usual) I think it was a fun experience and I'm already looking forward to the next session.

  • Being Cellfish

    Definition of Done


    Your favorite agile literature probably talks about the importance of defining what done means so everybody (team and product owner if we use Scrum terms) knows what we mean when we say something is done. And having a catchy acronym to remember what your definition of done is is in my opinion a good thing.

    When I did my Scrum certification a few years ago I learned an acronym that was a suggestion for what done meant. The catchiness in this acronym is that it is the Swedish word for done:

    Kodat - Coded/Implemented
    Levererat - Delivered/checked-in/published
    Accepterat - Accepted i.e. solved according to agreement
    Redovisat - Documented
    Tested - By developers and QA
    So translating this to CDADT or IDADT isn't really that catchy in my opinion. My current team came up with a different acronym without really looking at the Swedish example. The result:
    Designed - discuss design/solution with peer(s)
    Implemented - for code: coding guidelines including comments apply
    Reviewed - Solution reviewed before check-in
    Tested - work with QA to make sure team tests everything QA wants team to test but not things QA will test anyway.
    Now that's a catchy acronym in my opinion! Especially since it is supposed to increase quality. Irony is so funny in my opinion...
  • Being Cellfish

    Cash register feature

    A funny thing I've experienced here in the US is how the cash register systems at Fred Meyer and QFC (two large food store chains which apparently have the same owner). Most stores have offers where you get a discount when you buy more than one item (2 for $5 or $3 each). The funny thing about Fred Meyer and QFC is that you get the discount even if you buy only one item. So obviously their cash register software does not handle "group discounts" or they do not know how to configure it. Or it is a hidden feature which benefits the observant shopper. Either way; I like it.
  • Being Cellfish

    When to write passing tests before fixing a bug


    If you're a BDD/TDD practitioner you're probably used to create a failing test whenever you have a new bug reported and you want to fix it. But sometimes a situation arises where you have to do the opposite; creating a passing test before you fix a bug.

    Let me explain with an example. Let's say that you have code that uses date and time to calculate something. It all works fine. Then you go into daylight savings time and the test fails. Your first reaction might be to change the code to work but since you only have one test you might end up changing the code so that in half a year when you stop using daylight savings time the test fails again. So a better approach to handle this problem is to first create a test that passes before you change the code. Once that is done you have your (old) failing test and you fix the problem. Now you know you have code that works both with and without daylight savings time.

  • Being Cellfish

    What is a good team size?


    Your favorite Scrum book will say "seven - give or take two". If you look at group theory (such as FIRO) you'll see things like "five through eight" or "if the group is more than ten people you'll have smaller groups forming within the group". Another interesting way to decide on team size I read about is the "two pizza rule"; If you can't feed your team on two pizzas or less the team is to big.

    I think this a great way to describe maximum team size since it's funny and I guess it sticks. There might be a problem though since pizza size may vary. Two typical Swedish pizzas would not feed more than two or three hungry developers. If you go family size (or a typical US pizza I guess) you easily feed around five hungry developers. But I guess that is over analyzing the two pizza rule... Don't do that... Just buy two pizzas!

  • Being Cellfish

    Team Rules


    Some teams come up with a number of team rules that are posted next to the task-board. The idea is to have a number of rules that everybody in the team are committed to follow. And there is typically one rule at the top:

    Anybody can remove a rule they are not committed to at any time, this rule excluded.

    I think this is a great exercise to force the team to talk about their expectations on each other. Because rules can be anything from detailed practices to general things. So the discussion is actually more important than the resulting list of rules in some cases.

    An observation we made in our team when we recently had a team rule discussion is that the word "rule" implies a punishment when not followed. So in my opinion a better word for this exercise is "team values" because that's what we're discussing. A number of common values that the whole team have the same understanding of. Because if you just list a number of values without discussion the meaning, then different people with interpret them differently. So what kind of values can a team come up with? Well here are a few examples:

    • We should always check-in better code.
    • Our definition of done is XXX.
    • We should eat lunch together each day.
    • We should use TDD/BDD.
    • We should respect meeting start- and end times

    Do you have more examples of values you think a team should consider?

  • Being Cellfish

    Kanban vs Scrum

    Yesterday Henrik Kniberg published this draft on Kanban vs Scrum. I think it is a great article describing the differences (and similarities) between Scrum and Kanban so you should take the time and read it since there are times when a Kanban approach is better than a non-Kanban approach (and vice versa). I also like the fact that Henrik ends his article by pointing out the importance of retrospects. And if you wonder about when to have retrospects in a team using the Kanban approach I suggest reading this.
  • Being Cellfish

    Agile Managers


    A typical problem in an organization "starting to be agile" is that some managers (typically middle managers) don't see where they fit into the new process. So in order to complete the transition successfully you need to have especially middle management in the plan. At a talk at Scrum Gathering 2008 it was mentioned that middle managers should be involved early and encouraged to participate in the process of identifying their new roles.

    So what are these new roles? If we use Scrum as an example (because it is popular and has three well defined roles) it is obvious that managers typically don't are part of the team. They're manager and often cannot contribute to the sprint just like any other team member. Managers also typically dislikes being demoted to team members. They worked hard to be managers...

    So many managers thinks Scrum master sounds like a new cool title for them. I think this is where many companies go wrong. The Scrum master is not a manager. It's a coach, facilitator and guardian of the process, the team and product owner. As such the Scrum master must be skilled and be really excited about the cause. Another warning. Even when the manager actually has the skills and desire a Scrum master needs it might still be a bad idea making him a Scrum master because of the risk that the team will hear him speak as a manager and not Scrum master hence "following orders" rather than "listening to advice".

    So that leaves us with the product owner role. In my experience companies successfully adopting Scrum tend to make their former managers product owners. This way their old management backpack does not affect the team's evolution and also the managers are doing what they've always done; prioritizing and deciding what the team should do (but now in a new way).

    Sometimes the manager is not skilled enough to be a product owner because someone else has more knowledge of customer requests and so on. Don't panic! In my experience people with good knowledge of what the customers really want often feel they have little  or no time to spend with the team. So even though this is not an ideal scenario the former manager can step in as a product owner proxy when needed. You can also be assured that the team will come up with a list of impediments they cannot solve. So you as their former manager can come to their rescue help the team unblock some impediments.

    And even if you're not the Scrum master nor the product owner you can still help the team by coaching them toward "better". For more tips on what managers can do read about daily stand-ups and impediment involvement.

  • Being Cellfish

    Fixing disk configuration/statistics mismatch on HPUX


    I recently was involved in troubleshooting a problem on a HPUX system.It turned out that the system command iostat showed one disk and the configuration (/etc/lvmtab) showed another disk. Yet another symptom was that lvdisplay didn't work at all. Since there had been a bunch of activity on that system it took some detective work to find out that the reason for the problem was that the raid controller had been replaced.

    So this still amazes me. The configuration said one thing and the monitoring tools another but still the host worked just fine. Actually it was a little slow but apparently the mix-up of disk devices didn't matter. So when other systems have their hardware changed you need to rescan it so how do you do that on HPUX? Well this is how you fix your disk configuration if you have one volume group named "vg00":

    In multiuser mode:
    #/sbin/vgexport -m / -s -p -v vg00
    Reboot the system and go to maintenance mode:
    #shutdown -ry 0 [Esc]

    Main Menu: boot pri isl
    Interact with the IPL?> y
    ISL> hpux –lm

    #/sbin/vgexport -v vg00
    #/sbin/mkdir /dev/vg00

    Create the special device file (SDF), use the next available minor number:
    #/sbin/mknod /dev/vg00/group c 64 0x##0000
    #/sbin/vgimport -m / -N -v -s vg00 vgchange -a y vg00

    Reboot the system to multiuser mode again.

    Preemptive comment response: No I don't know why the system was not reconfigured immediately after replacing the RAID controller. Probably because everything seamed to work after booting.

Page 1 of 2 (14 items) 12