With all sorts of code metric analysis, unit tests, code coverage, selenium tests, and automatic deployment scripts, you should think that you got most of it covered. But there are other ways to check you code and one of the best is probably gut feeling and common sense reviewing and reading code.

But just because you find code smells and code that start to fall apart doesn’t mean you have the time or want to break your flow with a big restructuring or even a smaller refactoring. You want to  mark it and later get back to it. So you place some comment there, like a TODO or NEEDS WORK and what happens?

Two weeks later you find the TODO but still don’t have the time to do the job properly or you cannot even remember why you put it there in the first place. And when is there time to take care of this code.

In the current team we try to collect bigger restructuring and refactoring to refactor Friday. We are not allowed to add new features during this day, only clean up and clarify the code. So we try to find the TODOs and comments or even collect some comments on our scrum board but we need more structure and a better way to handle code smells.

So we came up with a few ideas for this. The first part was to add a .NET attribute that we can add to classes and methods that we find need work. The found code smells are now marked with an attribute as follows:

[SmellyCat(LevelOfSmell = "This one reeks", 
    YourCodeSmellsBecause = "It’s unreadable", 
    IFeltTheSmell = "Sniffy")]

The attribute includes a way to add details on why and how bad the smell is to be able to handle it later on and maybe give it priority.

The next step is doing something with all these attributes. A custom task to MS build looks like a good start, this is on it’s way and will produce an output that we can include in our code analysis section in TeamCity, currently it produces an XML file so the next step is to add some XSLT and produce a lovely HTML file to include as artifact in TeamCity. The goal here is to find a good level for this build task and simply fail the build if we have to many code smells in the code. Forcing us to take care of the code smells before it reaches unbearable levels of stench.

// Håkan Reis

To make it easier to use other blog engines and change feed settings (and sell the last shred of my soul too Google). I started using the Feedburner service. The service gives me some more statistics as well, but that’s not the most important issue here.

I wanted to change the underlying engine for my site and, well it’s not the the first time but it’s annoying to force the users to update their readers just because I want to use another engine. So from now  on you can always use the Feedburner link to my feed.

Now if I only could handle all the cross links and URL rewriting as well…

// Håkan Reis

I have been writing about agile interaction before in Agile Usability No 1 and after that in Agile Usability No 2 - AID. Also a post I did November 2006, Refactoring the agile manifesto, tries to induce some interaction design thinking in the agile manifesto.

Still there are a number of things to do in this area. For some of us agile development is old news, but actually it has just begun and interaction designers should take this opportunity to get more involved in the process. As I attended from business to buttons earlier on I was alarmed by the lack of understanding in agile software development. I really think there are actions that need to be taken now.

More and more I have found that interaction design needs to be split into two parts; backlog creation and software interaction design. And it seems that Alan cooper backs my view on this even if I don’t agree with all he says.

Backlog creation

The interaction designers really are the ones that can translate user needs to user stories. They have the ability to explain end boil down real user needs and goals to user stories that developers can understand. The interaction designers have the tools to create vivid scenarios. And from them extract all the user stories needed to create a compelling and rich user experience.

Software interaction design

This part is done in tight co-operation with the developers. Churn out sketches and prototypes together with them, make sure they get the designs and purpose and at the same time learn about the boundaries of system. What is possible to create and what shortcuts can I use. No more documents or Photoshop mockups that just get’s handed over to the developers. The result is quick feedback with with bits and pieces of working code and interaction that can be used in user testing.

Wireframe tools may be useful for early testing of concepts and ideas but I actually think that Microsoft is right on track with their, still rough, set of tools. In the Expression suite they try to make a solid split of design and development, enabling parallel cooperative designer/developer work.

Get rid of big up front design

Still there are interaction designers out there that think they can come up with a bunch of user studies, wireframes and flash prototypes and just hand them over. I’d say they have to adapt or start looking for a new career. We really have to work together on this.

The interaction designer in a scrum team

Interaction designers are full grown team members. Obey the rules of the scrum team and get the flexibility and trust as a team member. Always strive to improve and streamline the process at every sprint retrospective. It’s time for the interaction design community to create their set of tools for the agile process. It may be tweaked versions of current research tool box or something completely new. But this is our chance to get as involved and the users need us to be.

// Håkan Reis

For a few this years conference has started already with workshops and educations. But the big event is officially started on Wednesday. As usually it will be bigger, better and even more awesome than ever and I will be there-

Let me know if you are there and we can meet up, will be in the Waygroup booth at Monday representing Dotway. We just got a flicker feed up for all the pictures that are tagged with oredev08, check it out and contribute.

// Haqwin

I have wrestled with a problem for days The problem was that I didn’t get coverage for all assemblies that were tested. No errors, no exceptions, no problem whatsoever in the builds and tests. But no matter what I did, the tests did not produce the expected coverage. NCover  and NUnit-console just spits out a coverage report with large holes in it.

As it turns out, all boils down to how NUnit treats the assemblies and the program database files (PDB) while testing. And avoiding shadow copies while executing tests on the build server.

Some background

A couple of weeks ago we made the move from CC.NET to TeamCity. At the same time we restructured the solution folders, having problem with dependencies on builds and that scripts took forever to finish. So to speed up the feedback loop for the day-to-day development we needed the new structure.

Setting up the new structure took about one day of work and creating the initial build and test loop for development another couple of days. This without any build scripts at all. The deployment took a bit longer and involved a few MSBuild scripts and it works well now. Also in this is a setup for executing selenium tests, this took some more scripting but finally it’s in place as well.

The problem

The final piece of script was the coverage. Unfortunately there are no integrated support for NCover in TeamCity so you have to revert to good (or bad) old MSBuild scripting. As there a few long running tests in this soup we opted for running coverage at nightly builds. The dev coverage can be executed on the developer machine so there's no problem with this.

So after setting up a converge build for each of the solutions I found that it never produced the same result for all solutions. With no apparent problem, assemblies was omitted from the result. And sometimes it worked as expected. After more analysis it turns out that when one solution has been built it affects the coverage of other builds. More than was explained by the interface points between the solutions.

It got even worse, I did a build for project A, checked the coverage for A, then built project B and the result for project A changed. Checking the files used for instrumenting project A I could not see one single difference down to the timestamp and version for each and every file of the A build.

The solution

Finally I sat down with FileMon from SysInternals and did a check on one specific assembly used in the test to get a grip on what was tested and where it came from. Hmm, what is all this shadow copy used by NUnit? What happens here?

Well it turns out that NUnit copies assemblies to a temporary folder while executing the unit tests, this to allow the user to continue develop while the tests are executed. Well, this is not the problem on the build server. In the coverage run that I created the assemblies built are copied to an analysis folder and the tests are executed there. And the simple and working solution is to add the /noshadow option to the NUnit command. After checking with FileMon and the resulting coverage I finally got this last nagging problem solved.

After the various coverage results are merged with coverage explorer, it is now published with the working builds on our demo server. Automatic build configuration finally done. And less copying of files while testing might even shave a few seconds of build times.

By the way, now that I know exactly the problem and the solution, it was easy enough to find a blog post concerning NCover problems, that explains it all.

// Håkan Reis

A college of mine recently added a WPF showcase on Codeplex. We all need inspiration and this is a great place  to start. Here is not just a showcase of what you can do with WPF, there are panel, custom controls and shader effects. The collection is created along the way to try out various intrinsic of WPF as well as educational. Some has in one form or another made it into working applications.

So go grab it and start experimenting

// Haqwin

This is a rant. As much as apple has had its focus mainly on the user they are now heading in a new direction. The new iTunes addiction is sales, the new incarnation of iTunes is only about how to get the next fix, closing the next deal.

The sad thing is that as with many other companies that has reach world domination - it cripples innovation. There hasn’t been much innovation in the user interface since it was introduced years ago. The few is focused on one thing, selling stuff.

To start with, what is iTunes?

Well this is one problem, it has become a beast, to the user it is foremost a media player, or at least tries to be. It’s not among the better media players but it gets the job done. As a media player there has been added a few extra features like burning CDs, music sync to iPod and oh, it let’s you buy new music.

But later on they have added more and more bloat; iPhone calendar and contact sync, application sales, pushing media and stuff you already own, podcast, video downloads. Oh, and the updater doubles as a portal for pushing safari as well.

The iTunes beast of today

iPhone sync - Why on earth do I want my iPhone to start up a (now) bloated media player just to sync contacts, calendar details and some music? Why not a blazing fast slimmed down sync application that use the database from iTunes to get the playlists, media track and application that are stored there?

The pusher – For a long time now iTunes ha added a little arrow to each and every track in the library, clicking it took me to iTunes music store, so that I could easily - buy the track I already own. Not a big problem as you could just remove it with a little setting. But not anymore, you can solve it with a hack but how many user are able to do that? We are going to sell more whether you like it or not! And it gets worse.

The genius - Masquerading as smart playlist manager genius gives Apple a way to display even more buttons with the word BUY in them. Now they have taken up 10% more of my screen real-estate with lists of music to buy. The playlists are not that bad, but I guess using genres, artists and some randomness would create about the same result. 

Grid view – The latest “innovation” is the ability to show albums in a grid…wow. And the cover flow before that, that turns out to be, not that useful. I love Eye candy and think it can serves a purpose but adding a black blob with a reflection in the middle of the database grid that represent all your tracks doesn’t help much.

What they could have added

Folder watching – I tend to move my music around, as there are not enough space on my laptop to have all my music and there are no easy way to have a central place for all tracks I have a subset on my machine, about 10GiB of music. So why not just add some smart folder watching? Thankfully there are people out there that get it.

Re-sync of statistics – If I play my music on my iPhone it would be so easy to count and then sync that back, as well as what tunes I skip etc. that would be excellent statistics for that genius playlists…

Native OS support – I’m a windows vista user, I actually like vista, and applications should behave. This is not a new problem with iTunes. But when are you going to address it? Not in one single place have they added right click support. You know, we use it a lot in windows. Or even looked at the Visa UX guidelines. But then again, why would they add functionality to us windows user that would be missing for the Mac OS crowd?

There; now I can get back to syncing photos, buying ringtones clips of music I already own and let iTunes steal GDI and memory resources from my system.

// Haqwin