Kallokain

Finally, I have put www.henrikmartensson.org on Rails! I have rebuilt the site from the ground up with Ruby on Rails . It was a pleasure to do it. The visible changes are small. There are a few more menu choices, including a link to this blog. The site also lists the most recent postings to this blog. Behind the scenes, the site is now database driven. Articles, presentations and images are stored in a database and retrieved on the fly. This makes the site a lot easier for me to update and maintain. I hope this will encourage me to write more articles. We'll see what happens. I had an unexpected problem with reading the Atom feed from this blog. I tried two different Atom modules, but neither could parse the feed properly. Both had trouble with Atom entries that contained more than one link. The problem was easily solved with REXML and XPath. The current implementation is a bit of a hack, but I'll improve it in the near future. I think there is a blog post just waiting to be w...

Pascal Van Cauwenberghe at Thinking For A Change has made the kind of blog post I like the most: it's about me . Well almost, it is about the Variance Trap series and the Theory Of Constraints based software development simulations I have run. His post also reminds me that I haven't quite finished the series yet. One more article to go. Coming real soon now...

Paul Battley emailed me about a bug in Test::Unit::XML . Attribute strings containing entity references were reported as not being equal even if the strings were exactly alike. I fixed the bug, added an assert_xml_not_equal assertion for good measure, and made a new release. The assert_xml_not_equal assertion is the inverse of assert_xml_equal . It is mostly a convenience method. That is, it was convenient for me to have it when I wrote a test that compared attribute values. I haven't worked much on my open source projects lately. It is not that I have lost interest. It is just that I have been otherwise occupied. Thus I am doing defect-driven development at the moment. When someone finds a bug, I fix it. If I can make some small improvement without spending a lot of time on it, I do that too.

Joel Spolsky has written an interesting article about how to organize and run software companies. Here is a quote: The command-hierarchy system of management has been tried, and it seemed to work for a while in the 1920s, competing against peddlers pushing carts, but it's not good enough for the 21st century. For software companies, you need to use a different model. And here is another: ...if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings? I think you will find the article an interesting read.

At Google, they have an 80/20 rule . Developers spend 80% of their time on work that has been assigned to them, and 20% is their own time, to spend on projects that are just interesting . That is one day per week that a Google employee can sit thinking things through, dreaming new stuff up, and implementing it. Does it work? AdWords was created this way , and it is a major revenue maker. Google employees seem pretty enthusiastic. Google does attribute part of its success to the system. It seems to work very well, at Google. Of course, at Google they have a pretty open and enthusiastic attitude to new ideas. "When someone comes up with a new idea, the most common response is excitement and a brainstorming session" according to a post by Joe Beda at Google. According to Beda, managers at Google actively encourage employees to come up with new ideas. It is something to think about.

Pascal Van Cauwenberghe has posted an interesting article on the danger of succeeding with Theory Of Constraints. He is quite right. If your part of a process has been the system constraint, and you elevate it, some other part of the process will be the new constraint. The people responsible for that part of the process may be rather unhappy with you. A friend of mine took a job as a subcontractor. He finished his job ahead of time, with no defects at all in his work. His manager was not happy. My friend was accused of "idling", because he had finished ahead of schedule. The idea that it was the manager who was slow in obtaining more work was of course never under consideration. Nor was it ever under discussion that if the contract had been anything other than a time-and-materials contract, finishing early would not have reduced the net profit. Quite often the slowpokes protect each other without even realizing they are doing it. I once worked at a company where nothing ha...

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 .

This installment of The Variance Trap compares two similar development process simulations. They differ mainly in the amount of variance in production capability in the process stages. As the animated diagram shows, there is a great deal of difference in productivity. (If you haven't read the earlier postings on this topic, you might find that reading part 1 , part 2 , and part 3 makes this posting easier to understand.) The animation above shows the result of two development project simulations. As before, the simulation model is extremely simple, with no errors or feedback loops. To simulate variations in productivity the simulation system throws a die for each process stage, for each tick of the simulation system clock. The yellow line represents a simulation with a six-sided die. The blue line represents a three-sided die, with two added to each die roll. (A computer has no problem rolling a three sided die. If you want to do it for real, use a six-sided die, count 1-2 as 1, 3...

I had forgotten to add a link to my Atom feed in the Kallokain page template. Thanks to Chris Headgate for pointing it out.

If you read the 1st and 2nd parts of The Variance Trap, you know how statistical fluctuations can slow a project down to a velocity far below the velocity of each of the stages in the process. I demonstrated the effects of statistical fluctuations with a simple game with a die, a set of bowls that represented stages in a project, and a lot of colored glass beads. (This is a slight variation of a classic example by Eli Goldratt.) I got tired of rolling dice by hand, so I started writing a Theory Of Constraints based process simulation engine. It is still very much a prototype, but today I wrote a computerized version of the beads and bowls game. I also managed to coax a simple animation from the simulator. It shows what happens with work buffers at different stages during the course of the project. The simulation is extremely simplified. For one thing, there are no feedback loops from the test stages (Init = Unit Test; Intgr = Integration Test; Sys = System Test; Acc = Acceptance Te...

I've had some very positive feedback about the Extract Mixin entry awhile ago. Pat Eyler wrote a blog entry about it, and Chris Hedgate also found it useful. In his blog, Pat asks the question whether Ruby will spawn a set of new patterns, or change the way we look at existing patterns. I firmly believe it will. It's not just Ruby though. Languages have different features, and they also emphasize different things, and have different cultures built around them. There is a lot to learn from immersing oneself in different languages and cultures. What you learn in one place, can often be used in another. I was a Perl programmer before I began working with Java. Perl taught me a lot about how to just get things done and that there may be more than one valid approach to solving a problem. This, I hope, fostered a spirit of openness. (Though it is really for others to say how that turned out.) It also gave me a different perspective on object oriented programming and design patt...

This morning I continued the variance fluctuation experiment I wrote about in my previous blog entry . I am going to show more details now, because it is interesting to follow what happens closely. (Well, it is if you are a management nerd, like me.) Remember that our original estimate, based on the average roll of the die, was that we'd get a throughput of 35 beads in an iteration. (An iteration consists of 10 sequences of 8 die rolls.) That prediction failed. The average throughput was only 28.4. The second try to predict the end of the project used another method. I used the average flow rate, measured over the first five iterations. This prediction indicated that 1.6 more iterations would be needed. 5+1.6, rounded up, is a total of 7. Let's see how the flow based prediction holds up. Here is state of the system two sequences into iteration 6: The first sequence had a throughput of 0, the second had a throughput of 2. I am not feeding the system any more beads, so we can exp...

This posting is inspired by the matchsticks and bowls game in Eliyahu Goldratt's book The Goal . It is hard to estimate projects. Everyone knows that. What everyone does not know, is that even if you get fairly accurate estimates for each stage in the development project, it is still possible, and quite probable, that a project will come in later than expected due to the effects of statistical variation. These effects can be proven mathematically, but it is easier, more fun, and more convincing, to do it with an experiment. Let's create a simple model of a project, and run a simulation of how variance affects development speed. When I ran this experiment this morning, I used seven bowls that represent the stages of the project: Analysis, Design, Code, Unit Test, Integration Test, System Test, and Acceptance Test. I used colored glass beads to represent ideas that are transformed into customer valued software features in the development process. To simulate the variance in produ...

Here is the story of a famous skunkworks project at Apple, the Graphing Calculator. It provides fascinating insights into how and why software developers work. Also, it is a fun story. My favourite quote from the story is: "I asked my friend Greg Robbins to help me. His contract in another division at Apple had just ended, so he told his manager that he would start reporting to me. She didn't ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive." Arguably, Ron Avitzur, who wrote the story, was in fact the project manager, but he certainly did not think of himself that way. It is unlikely that anyone else did either. He just did what had to be done to make the project work. Sounds to me like Alistair Cock...