Kallokain

I once worked in a Java project where cross-cutting concerns where a big issue. One of the problems was logging. Error handling was another. Logging and error handling code was sprinkled throughout 15 MB source code. Fixing it was no picnic. Today, I once again had reason to reflect on how to separate cross-cutting concerns. This time in Ruby. For example, if I have a Ruby class like this: class TemperatureConverter def celsius_to_fahrenheit(c) 9.0 / 5 * c + 32 end def fahrenheit_to_celsius(f) 5.0 / 9 * (f - 32) end end it would be very nice if I could add a cross-cutting concern without having to modify the original code. I would like make the methods in the class loggable by opening the class and declaring that I want logging, like this: class TemperatureConverter loggable_method :celsius_to_fahrenheit, :debug loggable_method :fahrenheit_to_celsius, :debug end How do I do that? I can add loggable_method as an instance method to Object . Object is the parent class of all other cla

Noel Llopis who runs the Games from Within blog has posted an interesting article about a day in the life at High Moon Studios , the Agile games company were he works. High Moon Studios uses Scrum and Extreme Programming. Judging from the article, they have got it down very well.

Scott Klebe asked me a very interesting question in a comment to my previous posting: does my research show whether other planning techniques are effective in increasing predictability? Here is my reply . The short version of the reply is: yes, I believe some methods are effective, but if there is a lot of unpredictability, it is better to just track what happens and then extrapolate from the results. The catch is that the variance that causes unpredictability does not necessarily arise from within the project. That makes the effects hard to predict, and difficult to control. Expounding on this a bit further: in The Variance Trap series I have modeled projects as systems standing in isolation. This is a huge simplification. In real life, there is a lot of interaction between the project system, and other systems. A typical development team, consisting of a number of consultants (that's typical in my line of work) will be influenced by: Groups within the teams own organisation,

I have just set up a TocSim home page at http://tocsim.rubyforge.org/ , and made TocSim available on RubyForge. There is no gem package or tarball available yet, so anyone interested will have to download directly from the repository.

Sean P. Goggins has written an interesting blog entry about Orchestrating Enterprise Architecture . If you read it, spend a little extra time thinking of the idea of single and double loop learning. It is worth it. Do you work in an organization where double loop learning is common? If so, why not drop me a line? I'd like to know more about how your organization works.

This is the fifth part in an ongoing series of articles. You might wish to read part 1 , part 2 , part 3 , and part 4 before reading this one. Until now every simulation I have described has used an extremely simplified model of a development process. It is time to try a more accurate model, and see where that gets us. Here is the model I am going to use: (Click on the image to see a full scale version.) The numbers in the boxes at each stage in the process indicate how many goal units that can be produced in a single day. To this number, I add a random variation of +/- 2 units to represent fluktuations in production capacity. (Judging from experience, this is a lot less than in many projects. I want to err on the side of caution. 50% of all goal units fail at Unit Test. The effort needed to fix a defect at unit test is 10% of the original effort. Integration tests have a 20% failure rate, and the effort to fix is 10% of original effort. System tests have a 10% failure rate, but since

I have poured all my spare time in TocSim, the Theory Of Constraints simulator, lately. Things are going well, but I have to constantly fight creeping featuritis. Declan , another of my projects, hasn't seen much development lately, but that will change. I am going to present it at XTECH 2006 in may. If you are going to the same conference, why not drop me a line .