Mickaël’s Weblog

Getting agile is probably the only (or best) way for large R&D organization in a software company to setup their workforce in front of their need. They usually are working over multiple products (legacy or not), and are market driven. In small software companies, the product management marketing function is endorsed by R&D management and they work usually on a small number of projects which are at least tightly integrated, which means R&D team is focusing on only 1 common goal.

Start-up have focused/sharp vision, excellent creativity. Large company are relying on strong market analysis and capacity to move on…most of the time as soon as a startup has demonstrated new markets.  Vijay Challa talk about this in his post on Agility World 2.0.So, they have to invest (put development resources) on the products depending on the market trends, profits from each product,…etc. That’s why its important to be able to switch developers from a product to another to be reactive.

Some agile principles helps for this:

• iterations and time boxed releases to have reactivity when some resources are removed from a project,
• sharing knowledge instead of specialization to be allow reallocation,
• pair programming to reduce learning curve when new developers are working on a new project.

I tend to think that agility is maybe not always that relevant for small company, but its certainly a must have for large software company to be reactive.

Agile methodology are based on the capacity to make the code evolving. Extrem Programing have some principles around that as simple design and continuous refactoring for example. Notice, that the aim is not to anticipate future evolution.

Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability.

All this is about complexity of code, but this does not means thousands or millions lines of code. Of course, having a very tricky algorithm written with a too large code base will create difficulties when an update will have to be done: a new developer will need time to explore this code before doing the change (maybe even do some prototypes). Even the author himself of the code maybe request additional time to test the change before checking in.

The Critical Code Mass can also be achieved on a very small code base, for example, when the algorithm have kind of magic: few lines of code, but it is not obvious how it work and even why it is working. Implementing a change can also be a challenge.

I think it is really important to take care of this Critical Code Mass if you do not want to let your program behave like a black whole. This evolution of the code is silent and do not appear suddenly. If all the development team is not aware of this and do not pay attention to avoid it, the projects evolutions will become more and more difficult and long.

I’m using Rhino Mocks and I’ve seen the real great feature “Ability to joke” when this (click on the image to see it as my theme does not have a main column large enough):

Finally my test was just wrongly written. I’m using RhinoMock and I’m very pleased with it, so I was really surprised by such message.
Ayende, don’t ask the step to reproduce of this, I’m not able to reproduce it and I did not backup my program at that time…sorry about that.  The only think I can tell is that I was playing with 2 threads in this test…and the test was not testing what it was supposed to.

My recent post on BDD was a little bit light and requires some deeper thoughts.

BDD versus TDD is part of hot topics that introduce too much pation too often…so I will bring my 2 cents.

The video that I mention is the post raise key points to my mind about BDD vs TDD:

• They are both Test first approach
• They are not incompatible and are not adressing the same kind of validation
• To some degree, BDD tries to validate behaviour and TDD tries to validate sate,
• They are both about validation,

Finally, I don’t think they should be opposed, and the pasion around this topics seams, to me, due to mis-understanding about the wording. What is sure, is that they can be used to express the validation of some code before writing it.

They are not incompatible: you can validate a controller for example using TDD or BDD. The test won’t be the same, they will introduce/guide different code to the end…but both will validate that the code works as it is suppose to. Some will rightly argue that you will use Mocks if your controller interact with a class that send SMS for example, and you do not want to pay for the SMSs that you are sending during your test. But using Mocks does not meant your are doing BDD: you can use stub and validate the state of the stub instead of the call to the Mocks.

I think most of the discussions are to some extend steril as both approach are usually both valide. Nevertheless, I found this video very interesting on the rational behind TDD (or BDD) and where it goes. I personnaly dislike the idea of 1 class = 1 test class (same for methods). I think that the grain and organization should be different. The validation that makes sense, is to validate a feature that represent added value for the end-users. This is were is the true BDD. To me BDD just extends TDD (as “test first”) by making the relation between code and feature. Decoupling code and feature is the best way to get better tests as they are close to the features. When I say better, I mean easier to maintain, breaking only when one feature breaks.

I recommend 2 great articles on this topic:

• BackgroundWorker and SynchronizationContext
• an excellent tutorail on multithreading in C#
• or this other excellent paper from Joseph Albahari

Management tries to dertermine a magic number between ideal days and real days. The rational is always the same: PTO, meetings, illness…etc.

But, even if an ideal developper would exists (never ill, no PTO and no meetings) there will always be some shift between estimates and time to developpe the feature. I see at least one reason which has a significant impact IMHO: he is not working alone! He will have to synchronize with the source control before check-in. This can be done efficiently if the SCM system is efficient and longer if not…or if there is no SCM system. The result of this synchronization is absolutely unpredictable.

Maybe, the “single brain” (a team of…1) is the right approach to get accurate estimates…but it has its own drawbacks.

The best is probably experience.

Another step before check-in which may be longer than expected is the refactoring.

Take the time to look at this vidéo, it’s one hour long, but worth it.

Agile methodology are far less adopted than traditional waterfall methodology. Is it due to a lack of maturity? Maybe yes. I think Agile methodology will continue to evolve and this is a good thing.

I think that agile methodology are misused and people is emphasing too much the test versus design which is not to me the original sense. The ‘behaviour’ is really the unit of mesure of the business value provided by a software.

I hope year 2008 will be great for all.

2007 was fine for me and finished with a big-bang in my garage !!

I’ve never seen that and the repareman … neither. We are not talking about an old-crapy-washing machine. No, only 12 months and 10 days. The funny thing is that the reparman wanted first to repair it !!

 J’espère que 2008 sera une excellente pour tous.

2007 a été un bon cru pour moi et c’est terminé avec grand fracas dans mon garage !!

Je n’ai jamais vu cela et le réparateur…non plus. C’est n’est pas une veille machine à laver que j’aurai récupéré de mon arrière grand mère. Non, seulement 12 mois et 10 jours. Le plus drôle est que le réparateur proposait en premier lieu de la réparer !!!