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