Biological clock


Ever wished you could track your menstrual cycle without needing to count days on your fingers? This tiny project here should do the trick.  It displays those days of the cycle that a women is most likely to conceive, if she sets the start of her cycle every month.

It’s easy to understand. If intercourse takes place when the needle is in areas shaded in green then conception is unlikely, the areas shaded in pink are more likely to conceive a female and the areas shaded in blue are more likely to conceive a male. It looks like this:

icon for bioclock

Biological clock screenshot

The black needle on the clock display the current day of the cycle, the red needle at the 6-O-clock position displays the start of the cycle. Whether your cycle ends exactly at 28 days or not, simply select the first item in the menu of this application to reset the cycle (the minute your new cycle starts, that is).

Send me email if you use this; if significant demand exists I will most likely make the following changes:

  1. Fix the pink/blue ratio to be equal in area and to fade in/out gradually.
  2. Change the calculation so that the clock will adjust to your personal cycle (for example, if your cycle is generally 26 days, the clock must use 26 days as a full cycle, and not 28).

The hypothesis for why certain times of the month are better for conceiving a male and certain times for conceiving a female, look at this research proposal over here.

Software Project Management


The Polaris Missile project was developed in the late 1950′s. The project involved 250 major contractors, over 9000 subcontractors and hundreds of thousands of individual tasks.[1] Many of the items and components needed for the project existed only on the drawing board at the time.[2]

The project was completed two years ahead of schedule.With 1950′s technology (i.e. pencil and paper) managing it. The complexity involved was almost unheard of at the time.

I find it hard to be convinced that the lack of success seen in most projects can be attributed to complexity, especially as most of the dev teams working on corporate Java (or C#, or whatever)  projects are probably working on problems that have already been solved in a different guise, or that need very little in the way of inspired or creative thinking. The hard mathematical bits are already done. The reason for most projects seem to be “lets reinvent $FOO in a different language/platform/design”.

Why then are project managers unable to accurately predict where the project would be after $X months? Could it be the lack of rigour, in that it’s hard to be mathematically rigorous when you are simply listing the activities with thumb-sucked guesses in a spreadsheet, without weighing each activity with a risk? Perhaps it’s because a technical meeting of 12 people is almost always going to result in 2 people talking at any given time and 10 not listening (‘cos the current conversation has no effect on them, nor should it).

Could it be that PM’s have almost no background in statistical methods, leaving them much more vulnerable to getting blind-sided by confirmation bias or misjudging statistical significance as statistical noise?

However, my singular experience with professional software development for the previous 12 years has put me in touch with numerous SW-dev PM’s, at many different companies, and none of them employed any of the methods or techniques used and created for the development of the Polaris Missile. Many of them were not even aware of it, having a more modern certification (PM’s on the Polaris Missile project had no PM certification) that presumably works better.


Or maybe I’m simply wrong, and development in Java or C# really is much more complicated than the advanced calculus and materials engineering needed to build a rocket.

[1] Production and Operations Management, Khanna, PHI Learning Pvt. Ltd., 2007

Harvard University Press, 1972