iPad is great for the casual media consumer who doesn’t mind consuming through the Apple controlled lens, but it doesn’t appear to be an appropriate business platform. They gave iPhones to all consultants at my last workplace, but this was really only an adequate tool for sales people who didn’t do much actual work.

Am I correct in thinking “the team” tracks the time it spends not directly contributing to the actual development process, and factors these metrics in planning?

In the past I have found it beneficial to let go of time as a concept for estimation. I may spend the same amount of time in each iteration, but what really matters is my velocity. And if my velocity goes down because I had to do other non-related work, this is factored into the next iteration planning session and I cannot commit beyond my bounds of delivery int the previous iteration (yesterdays weather).

Using this approach one loses the canonical baggage of estimating based on time, which is always frought with error, certainly in my experience…

Nick.

Fibonacci isnt the simplest scale you could use, and for those less mathematical, it might make little sense as a point system.

And ultimately, estimates have error in them, by definition. They are a dynamic metric of produceability within a microcosm of team collaboration, itself a changing system. Often when ideas are used to make estimates more accurate, I find its less agile and more oldskool thinking….”if only we could make those MS project reports better….”

The best modification of story estimation I experienced was one put forth by Matt Davey – working with smaller stories.

And finally I would say a better approach for the franken-fibonacci-stein estimation technique is to simply collaborate more during the iteration planning phase to understand better what the story involves. This alone can improve error, and its beautifully simple.

Nick.

And Doug, thanks for collecting links. Two “t”s in “Elliott”, please?

Would you please fix the spelling of my last name to end in a double-”t” (in three places)? Name misspellings can be contagious on the web.

Also, in the section about Andy’s Chalkboard system, a stronger connection to my work was Pan (http://conal.net/Pan), which as you said represented images as their sampling functions. And thanks to very aggressive optimization and C code generation, it really was pretty fast. Vertigo (http://conal.net/Vertigo) extended Pan to 3D and generated GPU code rather than CPU code, which made it even much faster.

Cheers.

http://conal.net/
http://conal.net/blog/
http://twitter.com/conal

subscribed.

Adding the ‘assembly=’ fixed the problem for all my xaml files.

Yay!

The key things to replicate would be (in my opinion): the ability to specify sequences of events, and the ability to asynchronously subscribe to events as they occur (the “push” part of the inverted enumerator).

Good luck!

http://paste.dprogramming.com/dparyim7

Also, here’s the complete code, including the stuff that would normally go in a library:

http://paste.dprogramming.com/dpghtd5v

How’s it stack up?

In addition to the papers mentioned above, Conor McBride has this page on his website where he has continued to investigate this topic.

It’s also worth repeating that the subject of generating functions touches on many of the same themes (generating functions are often studied in “discrete math” classes, and roughly correspond to the kinds of datatypes used in the article above). The book generatingfunctionology covers this topic in detail.

Oleg Kiselyov has made the point that the Zipper is the delimited continuation of a traversal function (he argues that the derivative-type above is the “reification” of this delimited continuation as a data type).

Chung-chieh Shan explores the logical interpretation of delimited continuations, also making the observation that negative types correspond to full-continuations expecting a value of that type (this concept of continuations as values of negative type has also been covered elsewhere, but I’m not turning up any references at the moment).

sigfpe observes that the interpretation of infinitesimal values in differential calculus holds for types (i.e.: infinitesimal types are linear types). Thomas Ehrhard and Laurent Regnier further this idea to a differential lambda calculus.

Edward Kmett tries to lift automatic differentiation to the level of types. He also delves deeper into the differentiation of types, finding corresponding concepts for e and sinh/cosh.

That’s about all I could come up with off the top of my head. This is still a very active topic of research, and there are a lot of angles that people have explored.