Tuesday, March 21, 2006
Design, Value, Cost
During the last few business trips, I've spent some time working on a probabilistic estimation tool (see some of my previous postings on this subject). Early on, I decided that the user should be able to see the probability density and distribution, both at the activity level (from some parameters he will set) and at the project level (through a Montecarlo simulation). From previous experience with other tools, I expected Montecarlo simulation to be somewhat slow, so I provided a button to trigger the simulation. Unfortunately, that means the results can get stale if you add or modify activities and you don't run the simulation again. It's unwise to keep stale data on screen, unless you clearly show the user that the data is indeed stale. This makes the design more complex, but classical linear thinking will keep you working hard until you're done.
Alternatively, we may just reconsider the simulation speed. Does it have to be slow? If we could somehow speed it up, it could be run automatically whenever something changes, and we'll never have stale data. Note, however, that it has to be reasonably quick, so that it can be run in the main thread. A separate thread for simulation looks like hard work again.
A first way to gain some speed is through careful coding. Choosing good algorithms and libraries, or writing your own, can be useful as well. I'm using C# for this tool, and it runs reasonably fast. I wrote my own random number generator with the triangular distribution I need; at last, some of that math in Knuth, "The Art of Computer Programming, Vol 2", is proving really useful :-). Right now, an accurate simulation with a small project takes a fraction of a second, and I'm pretty sure I can squeeze a little more performance out of it. This would be enough for small project simulations, but not for larger ones.
Rethinking the user interaction (not simply the "user interface") is another way to remove some hard work. My recent idea is to remove the button and simply provide a combo (or a couple of radio buttons) for the accuracy of the simulation. A Montecarlo simulation takes more time to give back accurate results. Therefore, users could set the accuracy level, and get faster or slower response. If they change the level, the result is updated. There is never stale data on screen: it could be calculated at a less accurate level, but it is never stale. The design is very simple: at the end of the game, the "accuracy" is just a number of iterations.
So here we are: better user experience, easier code. More value, less cost. I kinda like it :-).
