Being Cellfish

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

Change of Address
This blog has moved to
  • Being Cellfish

    The implementation of iterators in C# and its consequences


    Recently oldnewthing wrote a series av articles on C# iterators. Especially part four is interesting since it describes how iterators can be used to simplify asynchronous code. I'm not a big fan of this kind of exploit of a programming language since there is a risk the code is harder to understand for new developers looking at the code but it is never the less intriguing to read about.

    Now you should not skip ahead and read part four first. Read them all in order: one two three four

  • Being Cellfish

    Being agile when there is no project


    Sometimes I come across a team saying; "We can't use Scrum because there is no project. We just do what needs to be done on a daily basis." These are typically support teams, teams with a large support responsibility or teams with a lot of small projects running in parallel. On a rare occasion it is a marketing team who have seen the benefits in the development teams and want to be as successful but can't see how they can use Scrum. Well text-book scrum is not a good place to start. A better place to start is my previous guide. Having daily stand-ups are typically no problem in these teams. That is a good start but without the retrospects there is no obvious way to improve the process.

    Most teams tackle this by having retrospects at regular intervals even though there is no iteration. And this typically works well. Recently I however heard of a team doing it a bit differently. They had a piece of size A3 paper on the wall and as soon as somebody thought there was something they could improve they'd put a post-it note on the A3-paper. Once the A3-paper was full, they had their retrospect. So instead of having regular retrospects they had them when there was a significant amount of things to discuss. This makes the retrospects "polled" when needed which is a very much along the lines of the kanban-philosophy I discussed earlier.

    Actually using a kanban-board is another thing I would recommend these teams to use. The only practical alternative is to have iterations of one day length and we have to be a little bit pragmatic here. But the use of a kanban-board very well mimics the typical work of these teams. They typically have a short backlog of things to do for the next few days and as new things come in, it is prioritized and queued. Limiting the number of things that are worked on in parallel (as the kanban-board helps you to do) will help the team focus and also give outsiders a better view of what is going on in the team.

  • Being Cellfish

    How to avoid having too much work in progress


    Most teams I worked with have at some point had a lot of work in progress. Sometimes virtually the complete sprint back log have been in progress. This is definitely a bad sign. The reasons for this situation to arise are many. It can be bad break down of tasks meaning several tasks need to be worked on simultaneously to get progress. Or it can be that tasks are blocked because of some external factor. It can even be because the team are not focused and works a little bit here and there instead of completing tasks. When the iteration end comes closer it is not probable all tasks will be completed since even if each task only need a small effort to be completed there are too many in the end.


    So having too much work in progress at any given time makes it hard for an external observer to see progress and it makes the team unfocused. All teams I worked with have quickly seen this problem and addressed it at a retrospective. And I think the only solution I've ever seen is that the team commits to be more disciplined and completing tasks before taking on a new one and make sure the tasks are things that can be completed by it self. And this is often enough. However there is another thing you can do that also solves other potential problems.


    You can use a kanban. A very good description on how to use a kanban with Scrum is available here. What the kanban approach is basically about is to limit the number of items that can be in progress. The Scrum-ban article also adds a few new columns not used in text-book-scrum in order to get more kanban feeling and a sense of pulling in the process. So this is a little more formal than just saying "we'll be more disciplined" and it is also measurable. So what other potential problem does the kanban solve? Well, even though the backlog is prioritized there are times when the team, for efficiency reasons, might change the order they want to work on tasks. Having a ready column between to do and in progress (once again I must refer to the Scrum-ban article) is a very good way of visualizing the difference between the team's decision "what to do next" and each team member's "what to do next". Also having a small preparation queue like this will more likely identify blocking issues even before a team member actually tries to start working on an item. I think this helps the team identify these potential blockers early.

  • Being Cellfish

    Building robots with your windows mobile as a brain

    I just read this article in MSDN magazine about a robot controlled by a windows mobile. As I wrote before, I love robots. So this is yet another spare time project I fear will never be launched... Yet another up-side with the WiMo code is that it serves as an excellent example on how to communicate with BlueTooth devices and intercept SMS messages in your Windows mobile applications.
  • Being Cellfish

    Using CSS to fetch user browser history


    If you know what you're looking for in the user's browser history there is a pretty simple way to check if the user have visited a certain site recently or not. Basically you can create an invisible iframe with the link(s) you want to check and then use java script to query the appearance of the link. CSS tell you if the link is visited or not. A more detailed description on how this works can be found here. The way this exploit is used there is actually quite nice I think, since it enhances the user experience. And I have no problem with ads customized to match my browser history. I usually don't see them at all because of the ad blocker but if I could get ads that I'm actually interested in this would also enhance my user experience. So far no harm done. I guess the problem with this exploit is that phising sites like those impersonating a bank or paypal could now customize their phising attack to match the bank (or other service) the user actually have visited recently.

    If you use Firefox (which have tried to fix this since 2002) there is a plugin to fix this.

  • Being Cellfish

    Spending money to improve team productivity


    When adapting to agile philosophy some managers get carried away and want to spend some money on improving the team productivity. Especially if you have an external consultant coaching the team, the manager tends to ask the coach what they should buy. Often the budget is presented as "$X per developer". As a coach it is always nice to hear that the management recognizes the benefits from the new methodology and wants to improve it even more but it is only once in a while the question is correctly asked. First of all the question should be addressed to the team and not to the coach. A very important part of the agile process is trusting the team to improve its own process. Second the budget should be for the team and not for each member of the team (it is a big psychological difference how you present the budget).

    So now that the team have their fate in their own hands it is not uncommon to have them turn to the coach for inspiration. Nothing wrong with that. So here is some inspiration:

    • Get super sticky post-Its. Every time one falls to the floor you planning session is paused. An alternative I've not tested my self are sortable post-It cards.
    • Get more white boards.
    • Get a second monitor for each work station.
    • Get a nice visualization of the build status. A monitor at the coffee machine, a modified traffic light or just a number of lava-lamps visualizing the status of the last automatic build.
    • Have team activities such as lunches, beer, donuts or more traditional team building activities. Personally I prefer simple reoccurring team activities over expensive team building activities. If people talk to each other outside their work, they will probably talk more to each other while working. And often talk about their work at these social gatherings.
    • Formal training. Examples: BDD/TDD, Scrum, XP.
    • Get an Xbox and a number of games (or some other kind of game team members can gather around to let off some steam).
    • Get Resharper. People tend to not wanna live without this one once they start using it.
    • Improve performance of work stations and/or build server.
    • Get nice chairs.
    • Hire one more developer to ease the work load on the team. Gives the team more time for personal research and education. Do not confuse this with adding more work to each iteration.
  • Being Cellfish

    Hiding or disabling menu items not available?


    About a month ago Joel Spolsky wrote a very short post instructing people to not hide or disable menu items that are not available. This I've been working on one of my spare time projects this summer - a project that involves a web based user interface I've given this some thought. At a first glance Joel's recommendation makes sense. At least to me since I've several times found my self in a situation where I see a disabled menu item or button in an application and I know I want to use that command but I have no idea what I needed to do to enable the option. Under such circumstances I would have loved the developers if they'd let me click the darn thing and then tell me what I need to do.

    However, things are never black or white - they're gray. And different situations call for different approaches I think. I also think you should include buttons in this discussion. The good thing is that buttons can be handled in the same way as menu items.

    Hide vs Disable

    A user menu should never change its content due to application state. If menu items are hidden and shown the user will have a harder time recognize the menus. It is easier for the user to navigate the menu if it is always the same (except that some things are disabled from time to time). Same applies to buttons since there sooner or later will be a manual with screen shots and if the user does not see all the buttons they will think they have the wrong view.

    There is however one situation I think you should hide the menu item. That is when there is nothing the user can do to enable the item. This typically applies to security settings. If the user does not have access to a certain feature, and never will have unless somebody changes the security policy, it's just annoying to see that option all the time. Personally I hate those web sites where you try to access some page and all you get is a "you do not have access to this feature".

    Disable vs Enable

    If you disable an item you have to perform some kind of check when rendering the menu item (or button). You will also have to perform the same check when actually handling the click event in order to protect against programming errors and abuse by an evil user. Sometimes this check may be very expensive to perform. If the check is expensive to perform I tend to leave the item enabled (for a quick rendering routine) and then handle it once the item is clicked. But the error message must be descriptive and clearly point out what the user have to do in order to complete the action.

    I would also leave the item enabled if there is a complex series of actions the user have to perform in order to enable the item. I think it is better to let the user get a descriptive error message telling him what to do rather than just disabling the item.

    Another thing to consider is that many users are afraid of pop-up error messages and even offended since they think they did something wrong. And if you throw an error message in their face for something simple they think they'd understand if the item had been disabled instead they might get angry at your application (and you). You can't please them all but you should consider this. For example if you have an edit view that is used for editing and creating items you might wanna disable the delete-button when in create mode rather than telling the user "they can't delete an item that is not created" when they click it.

    Tool-tips are the rescue. Adding a tool-tip for each disabled item telling the user why the item is disabled is an excellent solution.


    So as usual in the wonderful world of software development, it depends. For items not available to the user at a given time, these are my recommendations: 

    1. If the user will never have access to the feature - hide it.
    2. If the user may access the feature but it is cumbersome to determine if so is the case - enable it.
    3. If the user may access the feature only after a series of complex, non-obvious actions - enable it.
    4. Otherwise - disable it, preferably with a tool-tip explaining why the item is disabled.

    If the item is enabled the error message when clicked (and the action fails) must be descriptive and tell the user exactly what went wrong and what he can do to complete the action.

  • Being Cellfish

    Be suspicious to DAL frameworks


    I've always been suspicious to SQL queries that are automagically generated by some framework. And when I read this article on lengthy SQL queries it certainly was another gallon of gasoline on the fire. Sure premature optimization is the root of all evil and all that but there is also another important rule in software development; Don't do obviously stupid things. If you want to use a framework for data access, which is very common for productivity reasons, be sure to design your software so it is easy to replace the generic framework with something specific.

    If you on the other hand end up with really large queries when you write the queries your self (I'm a stored procedure guy so I have a hard time even making up what kind of SQL query would end up being that large), but it is obvious what the solution is - Stored procedure.

  • Being Cellfish

    Recursively delete empty directories


    I recently had to find a neat way to remove all empty directories recursively on a Unix machine. In the world of UNIX you can expect to find a way to do things like this pretty easy. When I started to search for a neat way to do it (rather than reading a bunch of MAN-pages) I came across a really funny story on The Old New Thing. Windows users are so used to having to use an application to do simple things like this, they forget about scripting possibilities. Guess that will change with Power shell.

    However this was about how to do this on Unix. Well, this is my solution:

    find $1 -type d | sort -r |
    while read D
      ls -l "$D" | grep -q 'total 0' && rmdir "$D" 2>/dev/null

    That script takes one argument; a directory you want to remove if it and all its sub-directories are empty. Any directories encountered where files exists are preserved.

  • Being Cellfish

    Nothing is "Too simple to test"

    A common practice taught in many TDD classes is the principle of too easy to test. The principle basically says that you should not test really simple things since then you will spend time writing tests that not really add value.


    This is a fair recommendation and actually makes a lot of sense. Especially if you're implementing TDD in a team where people are a little bit skeptical. But there are a few dangers with allowing the use of this rule.

    • Exactly what is considered too easy to test may be different if you ask different developers. Those who are reluctant to embrace TDD tend to stretch this line quite far.
    • If something that once was really simple and then didn't need a test later on is changed to something more complex there is a risk that the developer will not add a new test since there was no tests before.

    Personally I think that if something is considered to be so simple it does not need a test, it must be really simple to test. And if it so simple to test why shouldn't you use it. The relative cost might be high but the absolute cost for adding a real simple test for some real simple functionality is worth it in my book since it removes the decision from the developer. "No new functionality unless you have failing tests" is much simpler to follow and remember than "no new functionality unless you have failing tests or you consider the functionality to be really simple". Also consider the code coverage issues.

Page 46 of 49 (482 items) «4445464748»