-
Get a monthly update on best practices for delivering successful software.
A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.
My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It's actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.
Continue reading »
Topics: agile, Estimating, Requirements, User Experience Design
One of the bitter consolations of mathematical Computer Science is that we can demonstrate that applying algorithms to analyze algorithms is a largely fruitless task. It starts with the halting problem (can we write a program that takes a program as it's input and determines whether that program halts on all inputs) and goes on from there. The proof is by contradiction and -- like most "assume not" proofs -- is largely unsatisfying, i.e. it doesn't construct anything useful that you could apply to other problems. As Professor Herstein once told me in undergrad algebra, "Kappe: assume not assume not."
That's one of the theoretical underpinnings of why some software bugs are so hard to detect and fix; in a large system, automatically diagnosing bugs is akin to solving the halting problem. But what if we just try to solve this problem for a really small subset of programs? Well, first, it would have to be a really small subset. And second, even with very simple systems, answering questions about correctness, such as "does it halt," can be surprisingly difficult.
Topics: Bugs, Estimating