Agile Design Artifacts

I recently got contracted by a company to be the technical lead for a web application development project. My first task was to come up with an architecture document for the application within 2 to 3 weeks. I rapidly realized that it was not realistic. I could eventually design the application, but I was convinced that it would not be efficient for the following reasons:

• I was promised to get the full requirements a week after I started. I did not get them and still now, after 3 months, there are still on going,



• The web application was intended to connect to a back end bought from a third party provider. We did not know much about the API (actually, the API were planned to change – and still changing today after 3 months)

• I always have been convinced that a too detailed architecture will be obsolete as soon as developers start to implement the functionality.

For these reasons, I told the team manager that I prefer not to spend my time drawing class diagrams or any sort of artifact that will be thrown away or, at best, be expensively kept up to date during the development process. What I suggested though was to:

• Draw a high level design diagram; this diagram included all the providers and layers of the application.




• Write few class stubs to give a direction to developers. The classes did not contain any implementation. They rather contained many “TODOs” with comments for developers; we also agreed with developers that the comments were there as a suggestion. They were allowed to go in another direction as long as they respect the overall design idea.




• We focuse on only one type of artifact: the code itself. Well written code is the best artifact as it expresses the static view but also the dynamic view of the system (which is, from my point of view), the most important view to understand a system especially to support it.




• We scheduled and took the necessary time to do few meetings with all developers to explain the design guidelines; this is far better than writing thick documents as developers came up with very interesting questions and suggestions from their past experiences. Once we agreed on the design, we started the development of what we called “the infrastructure” or the framework that will support the application.
  

During this phase, we decided to use SCRUM methodology; this was new to my client (they applied it partly in the past). I insisted on the fact that an iterative development process will help us to get things done and deliver high quality software.

We called this first phase the SPRINT 0; we did a lot of refactoring as the code was written and the application was growing in size. We decided that no interface (user interface) will be developed during this sprint; we wanted to focus only on the framework and the design.

Now, we are in the sprint 3. We delivered some functionality to the business and we had very positive comments so far. Even managers who first were skeptical regarding SCRUM methodology are now much more comfortable and confident that an iterative process can effectively help to deliver in time and with a high quality.

Visual Studio 2008 and .NET 3.5 SP1 Content

The link below is an article that details the new features and improvments of the Visual Studio 2008 and .NET 3.5 Service Pack 1.

Among other this service pack contains the following new features:

- ASP.NET Dynamic Data (ASP.NET Data Scaffolding)
- ASP.NET Web Routing Engine
- Support for SQL Server 2008
- ADO.NET Entity Framework and Linq to entities

Final release is planned for this summer and will be released as a free update according to this article.

http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx

Display .CHM Files content

If you download a Windows help file (.chm) and it does not display the content (all pages are empty), chances are that your file is simply blocked by Windows.

To solve this issue, simply right click on the file and click on the 'Unblock' button.

C# 3.0 Extension Methods

One of the new features in .NET 3.5 and C# 3.0 is extension methods. Extension methods, as their names state, let you extend any existing type by adding new methods without having to inherit from it.

For instance, one of the common issues we encounter when retrieving data from the database, is to check whether the value is DBNULL or not before we can use it. I used to write a DbReaderHelper class that actually implements ‘dbnull safe’ data retrieval methods. The syntax to declare an extension method is very simple. It is a static method which its first argument starts with the keyword “this” followed by the type we want to extend.

For instance, if I want to add a new method called “nGetInt32” which returns an Int32.MinValue if the field is dbnull otherwise the field value (an Int32), I should write it as follows:

public static Int32 nGetInt32(this DbDataReader reader, int index)
{
if (reader.IsDBNull(index))
return Int32.MinValue;
return reader.GetInt32(index);
}

How to use it?

The extension must be part of a static class (see the example at the end of this post). To use it, simply add the namespace the class belongs to as part of the “using” directives and that’s it. Even intellisense will take it into account;

Why using extension methods

If we want to extend the DataReader class to make it dbnull safe, we would have to inherit from one of its implementations and therefore would not be able to extend all inherited classes. The other advantage is the fact that you can extend any class (even those marked as “sealed”. On the other hand, extending a class has a limitation which is that the extension method can only use public methods and therefore there’s no access to the inner state of the object.

Methods resolution

- Instance methods have priority
- If the same extension method is declared more than once, the compiler raises an error.
- The compiler looks into the current namespace and all the namespaces included with the using directive.

C# 3.0 Anonymous types

With C# 3.0 you can declare a variable without typing it explicitly and its type will be inferred based on the right expression. This is different from the non typing in VB like languages (ASP, VB) as the resulting value is really typed and can no longer be assigned to a different type. Also, right after entering the line that declares the variable, intellisense becomes available.



We can see that actually the variable x is of an anonymous type with the two properties Name and EmployeeNumber plus the inherited properties from the Object class. If we declare another anonymous type variable with the same structure:

var y = new { Name = "Smith", EmployeeNumber = "199283" };

Then the new variable, y, is compatible with x. In another words, since it has the same properties with the same types (string, string) then C# compiler detects that x and y are of the same type even though we never declared it explicitly. In this case the instruction: x = y is correct and will result in affecting the value of y in x. However if we declare a third variable z:

var z = new { Name = "Buddy", Company = "Microsoft" };

and try to affect the value of z to x for instance, we will have a compilation error (and not a runtime error – typical for non-typed variables - ). Even though z has two members of string type, all like x and y, it is not compatible. The reason is that the second property has not the same name (company versus EmployeeNumber).

Some restrictions to anonymous types:

Anonymous types are only permitted for local variables. You cannot declare a class member with the var keyword. A method cannot return a var type neither can it has a var type parameter; all the following declarations won’t compile:

public int function(var x, int y)
public var function(int x, int y)

however returning a var variable value is permitted:

public int function(int x, int y)
{
var t = x + y;
return t;
}

The reason is simple : at the point of the ‘return’ statement, the compiler knows that ‘t’ is an integer and can be returned since the method must return an integer.

Why using anonymous types?

First, let’s calm down the spirits who think that this is a step back to untyped variables. As mentioned in this post, it is really an implicit typing and if you look at it closely, the variables are typed but the type is constructed ‘on the fly’ if we want. We can use it without declaring it.

This may open the door to poor programming if it is overused. However, the impact might be limited since the anonymous type has only the scope of the method where it is used. The main advantage of the anonymous types is in LINQ (beyond the scope of this post). I will post something on LINQ pretty quickly…

Well the only advantage I can see is to be able to manipulate temporary results in a collection of an anonymous structure and then do something with it without having to declare a very lightweight structure or class just to carry the results in one single method. I can see the usage in a data access layer class that has to process the result returned by a DataReader. But until today, we lived without it and never felt really a need for it.

As a conclusion, I believe that the real advantage is the LINQ query…. Which I will talk about in my next post.

Extend Team Foundation Server Trial period

I have tried TFS for few months using the trial version and got stuck when it told me that the trial period was over because TFS does not notify you beforehand that your trial version is about to end (as any other software usually does).

I did a quick search on google and found a TFS trial extender that worked fine for me. It extends TFS for an extra month which should be enough to buy your licence. Here's the link:

http://blogs.msdn.com/bharry/archive/2006/10/04/Last-word-on-TFS-Expirations-_2800_I-hope_2900_.aspx

Note that according the guy who did this utility, you can extend it only once.

Le développement itératif

Définition

Le développement itératif consiste à livrer des parties d’un système ou d’une application à des intervalles réguliers. Ces intervalles sont appelés Itérations. Une itération est donc une succession d’activités couvrant l’analyse des besoins, la conception des parties du système, leur implémentation ainsi que leurs tests qui, activités, aboutissent à la livraison d’une ou plusieurs fonctionnalités qui feront partie du produit final.

Approche classique (par étapes ou Waterfall en anglais) comparée à l’approche par itérations

Par exemple, imaginons que nous avons un projet de développement d’une application en ligne qui offre 20 fonctionnalités différentes (20 scénarios). Dans une approche par étapes :
On effectue une analyse complète pour élaborer et détailler tout les scénarios,
L’architecte livre une architecture détaillée de toutes les composantes de l’application,
L’analyse fonctionnelle et le document d’architecture sont transmis aux développeurs qui implémentent la totalité des 20 scénarios

• On effectue les tests d’assurance qualité sur les 20 scénarios
• On livre le produit au client pour des tests d’acceptation,
• On fait les changements demandés par le client,
• On livre le produit final

Notez l’avant dernier point : Pour passer au produit final, il est rare que le client ne demande pas des changements. Cela souvent provoque des retards dans la livraison ou/et des fins de semaines sacrifiées à travailler sur les dernières demandes du client. Dans une approche itérative, on garde les mêmes étapes que celle de l’approche précedente sauf que ces dernières se produisent en dedans d’une itération dont la durée est fixe et de ce fait, se répètent autant de fois qu’il y a d’itérations. Par exemple, on pourra décider que les scénarios 1, 10 et 15 vont être développés dans l’itération 1. Pour l’itération 2, nous aurons probablement des correctifs sur les scénarios 1, 10 et 15 plus quelques autres scénarios tirés de la liste complète etc…

Avantages du développement itératif

L’approche de développement par itérations offre les avantages suivants :

• Elle s’adapte mieux aux changements. En fait cette approche considère le changement comme faisant partie du cycle de développement d’une application et non pas comme un événement intempestif,
• Elle nous permet de détecter les risques très tôt dans la vie du projet,
• Elle permet d’ajuster les choix en termes d’architecture ou de conception graphique par exemple, très tôt dans le processus et non pas après que ces derniers aient été complètement réalisés (et donc les heures déjà consommées),
• Chaque itération est une expérience qui nous permet d’apprendre d’avantage sur les challenges que représente le projet. Par exemple, il est fréquent de revoir les estimations faites au début du projet après la fin des premières itérations,
• On donne la chance au client de visualiser le résultat des itérations et donc l’occasion pour lui d’exprimer des ajustements au fur et à mesure que le projet avance et non pas à la fin uniquement lors des tests d’acceptation,
• Le contrôle de la qualité se fait à la fin de chaque itération.
• Les développeurs restent concentrés sur une partie des fonctionnalités qui font partie de l’itération courante. Tout changement ou correction qui s’ajoute à la liste des tâches, doit être planifié dans les itérations subséquentes. Comme la durée d’une itération est relativement courte, généralement, les clients et chefs de projets acceptent d’attendre ce délai
• Le client est rassuré car il peut voir concrètement la progression du projet à travers la manipulation ou l’exécution de cas d’utilisations réels de sont produit

Règles de gestion des itérations

Afin de gérer au mieux les itérations, il est important d’observer quelques règles dont les plus importantes sont :

• Fixer la durée des itérations au début du projet : Une itération doit avoir une durée entre 2 et 3 semaines. Il est fortement conseillé que la durée soit calculée en semaines pour que ca soit facile à mémoriser
• Au début de chaque itération, tout les intervenants dans le projet, y compris le client, doivent se réunir pour discuter des l’expérience de l’itération précédente et déterminer le contenu de la prochaine itération
• l’équipe de production doit présenter un produit à la fin de l’itération. On entend par produit, un ensemble de fonctions qui seraient utilisables telles quelles même si, dans la plupart des cas, on n’ira pas en production sans le reste des fonctions. La présentation se fait en utilisant l’application (il ne s’agit pas de présenter des Power Point par exemple)

Évidement, il existe des exceptions à ces règles, surtout en ce qui concerne la dernière, dans le cas par exemple du développement d’une application serveur qui ne présente pas d’interface utilisateur et qui serait difficile à présenter partiellement. Aussi, typiquement, la première itération « Set Up » et la dernière « Livraison » sont un peu différentes des autres itérations. Dans la première, le nombre de rencontres entre les différents intervenants est souvent élevé et les livrables sont de type « documentation ». Dans la dernière itération, on s’afférera à corriger les derniers bogues et focaliser sur les procédures de déploiements (création d’une application de déploiement par exemple).

Conclusion

Les avantages d’une approche par itérations sont évidents mais l’application d’une telle méthodologie nécessite plus de discipline qu’une approche classique ou les intervenants (équipe de production) ont une certaine durée pour livrer la totalité d’un produit, et en dedans de cette durée, il n’y a pas de moyen de mesurer de manière précise la progression du projet. À la question du gestionnaire de projet « Êtes-vous dans les temps? » les développeurs vont avoir deux réponses, dépendamment du temps restant. Soit un « Oui » si on est encore loin de la date de livraison. Soit un « Non » si on est à quelques jours seulement de la livraison. La marge de manœuvre est alors quasi nulle et il est trop tard pour agir ou négocier des délais supplémentaires avec le client. En se mettant des points de contrôles à la fin des itérations, le gestionnaire de projet peut évaluer lui-même la progression du projet et sa marge de manœuvre sera d’autant plus grande qu’il aura détecté les dépassements dans les premières étapes du projet. Aussi, cette approche permet de mieux intégrer les demandes de changements et les commentaires du client. Le fait de ne pas les recevoir tous d’un coup à la fin des tests d’acceptation permet au gestionnaire du projet de mieux planifier leur impacte sur la date de livraison du produit final.

Convert from FAT or FAT32 to NTFS

Few months ago I bought an external hard disk for an emergency back up. Therefore, I did not notice that I formatted it with FAT32 until a week ago when I tried to install ORCAS Beta 2 on this same disk. Actually, I got stuck as the files of the virtual machine were too big to be hold on a FAT32 file system (over 4 Go) and I was wondering whether I could convert my disk to NTFS without having to format it and loose its content.
I finally got a solution that eventually worked fine and did not require me to back up all my files, format the disk and copy them back.

The solution lies in the CONVERT.EXE utility. To get a list of all parameters, type ”CONVERT /?” in a command shell window (Start –> Run –> type “CMD” then type “CONVERT /?”)

For instance, to convert a hard disk, type “CONVERT F: /FS:NTFS” (i.e. convert the hard disk F from FAT(32) to NTFS file system).

Note that you can add the parameter /NoSecurity so that the new created NTFS partitions will allow anyone to access the content of the disk (it is the same as giving access to All Users to your disk). This particulary usefull when converting an external HD that might be used on another system.

I also suggest you to run a CHKDSK /F in order to check the disk and correct any error on it. This will save you time because CONVERT will run CHKDSK prior to convert the disk and if any error is found, the operation is aborted and you will have to run CHKDSK manually to correct the errors.