Kallokain

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...

I added one more entry to my gaggle of links. It is a very good Theory of Constraints page .

Working...on...Theory Of Constraints essay. So tired... Need...more...brains... --- Actually, it isn't that bad. I have spent a large portion of this week, and the last, working on an essay that summarises the basics of TOC and Throughput Accounting. I have worked with agile methodologies for several years, and have now reach a point where it is time to stop, reflect on what I know, and check if the theory and my experiences match. So far they do, which is very nice. Management theory may sound boring, but it isn't. Right now I am focusing on the mathematical side of management theory, and it is fascinating how an equation can leap out at you and say things like "move those desks closer together, and that screen from here to there", or "if you move one person from analysis to test, you will make the deadline without overtime". Most managers, including me, go by experience, best practises and rule of thumb most of the time. This is a good thing. It makes for ...

I found ten rules for web startups that made a lot of sense.

I talked with a friend, who is a very, very good programmer, about why it is so hard to find sane management practises in software development projects. Most project managers I meet (with a few shining exceptions) know very little about good management practises and process control. My friend mentioned that IBM is moving to fixed price contracts for most of its subcontractors, and said he hopes other customers will follow. He pointed out that with time and materials contracts, there is no incentive for custom software development companies to improve their practises. I believe he is right. I am no friend of fixed price contracts. Most projects have considerable feature creep, not just because of sloppiness, but because new requirements are discovered during the development process . There may be no way for the customer to know at the outset of the project that a particular feature will be needed. For this reason, I am more in favor of other contract types, like staggered contracts, pro...

Culture is not a product of what management says, it is the result of what management does. - Bill Waddel in the Evolving Excellence blog, 24th of January 2006

If you are bored with all the new fangled Agile stuff, why not try a more traditional approach to software development?

I think I might have a previously uncatalogued refactoring here. This is an alpha version. If at least a few people find it useful, I'll do a proper writeup. Here goes: You have two classes or mixins with similar features. Create a mixin module, and move the common features to the mixin. This refactoring is applicable with languages that support mixins, like Ruby. Motivation The primary purpose of Extract Mixin is to eliminate code duplication. In this respect, this refactoring is very similar to Extract Superclass . There are some noteworthy differences: Mixins are not a part of the inheritance hierarchy. Thus, it is possible to mix any number of mixins into a class, or into other mixins. Consequently, mixins are more flexible than class hierarchies. Mixins can create instance variables, but this introduces the risk of naming conflicts. Therefore, this refactoring is safest with methods that get all their variables as parameters to the method call. Extract Mixin ...

I think I accidentally discovered two new refactorings today, Extract Mixin and Replace Mixin With Class . (I'll make detailed writeups in a day or two.) This morning I found myself in central Gothenburg with nothing to do for an hour before a meeting, so I ducked into a cafe, had a cup of tea, and began refactoring Test::Unit::XML. If you have had a look at the code in the assertions mixin, xml_assertions.rb , in version 0.1.4, you'll notice that it is fairly heavyweight, weighing in at more than 220 lines of code. This is a fairly large chunk of code, and all of it is for a single assertion, assert_xml_equal . A big part of that code is for comparing different types of REXML nodes, REXML::Element, REXML::Text, and so on. The node comparison code was split into fairly small methods, so it wasn't too shabby, it was just that it was located in the wrong place. It made sense to move that code to a class of its own. I did consider moving it to a mixin module, but in the end I...

I just checked some Test::Unit::XML download statistics over at RubyForge . Looks like 15 people have downloaded the package so far. (The chart says 18, but I have made three test downloads myself, so they don't count.) Due to the smashing success, I am going to treat myself to a bit more Ruby programming tomorrow.

Time for a development diary entry. I've just released Test::Unit::XML version 0.1.4, an XML test framework for the Ruby programming language. This release adds doctype comparisons to the assert_xml_equal assertion. There are also improvements to the documentation , and minor updates to the tutorial . Barring bugs, assert_xml_equal is now finished. The next release will feature at one more assertion. I'm keeping the releases really small in order to provide new features as frequently as possible.) Internally, the structure of the framework will change substantially. In version 0.1.4, the bulk of the functionality is in the xml_assertions.rb file. This includes a truck load of methods for comparing various elements. These will be factored out into a separate class. From release 0.1.5 onwards, xml_assertions.rb will delegate as much work as possible. Version 0.1.4 has 17 tests, with a total of 67 assertions. That's a lot of tests for testing a single assertion. Still, I...

I had a thought while doing a bit of editing on my previous blog entry . One thing that could be useful to software development projects is a set of patterns for project managers, like design patterns for programmers, or system archetypes for line managers. Most development methodologies have plenty of artifacts, but no management patterns. It may be that the systems archetype pattern language from Systems Thinking is a good fit for this. I need to cogitate a bit on this, and try a few things out, but I will return to the topic.

I visited the easyFair convention at the Swedish Exhibition Centre in Gothenburg today. I found three different vendors who sold project management software. All three products had functions for tracking the cost of a project. This isn't surprising of course. What I found interesting is that all three products used the same economic model to do it, and that model is wrong. Huh? How can that be possible? It is not as strange as it sounds. All three products had functions for tracking the hours worked by each project member, multiply it with the hourly cost, and sum the costs for all project members, like this: project cost = Σ(cost/hour * hours) A simple formula, but there is something missing. Try this one instead: project cost = Σ(cost/hour * hours) - profit The profit here is what the customer earns from getting frequent partial deliveries during the course of the project . (It's not the total profit from the project. Oh, how I wish for MathML support in more browsers.) In...

I just added a link to Poppendieck.LLC . This is the web site of the famous management experts Tom and Mary Poppendieck. Their book Lean Software Development is a must for anyone, customer, manager or developer, seriously interested in software development. There is a sample chapter here .