Builds failing by code smells


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.

LionIn 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

Feedburner feed


flame2 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

Agile interaction design … take 3


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