It is confirmed beyond doubt that I too have a chronic delusionary problem all software managers have. Its called over-commitment, or huge under-estimation of the unknown risks involved in the process by which software is created. In the world of software it seems a common problem though. Apple released its new iPhone 5 with a buggy maps application. Microsoft released a half-baked Windows 8 and Surface. I am sure whey they started planning for these projects they thought they would be able to finish well within time.
My usual rule of thumb is to double my estimate how long its going to take to build a feature. But double, it seems, is too less.
I think the problem with software planning is similar to how humans perceive complexity. If a system has a large number of moving parts all interconnected to each other, it is extremely hard to understand the network effects of each change you make to the system. Every change, however trivial it is, has a potential to propagate in an inter-connected system in surprising ways.
It is interesting to compare a software experience to a narrative, since both involve expressing ideas through words. A software system is series of instructions that runs into a length of a typical novel. The difference is that a novel is designed to be read from start to finish, but software instructions can be read from any point. Moreover, while a novel is static, a software embeds "inputs" from the user and often simultaneously from a set of users, each possibly entering conflicting inputs. Each of these inputs changes the narrative. Some of these inputs have minimal impact (like a comment) but some inputs can run deep, (like changing the "state" of an "object").
It is mind-boggling to design such a system not to fail. There are only three ways to be sure: test it, test it and test it more. This problem arises because software writers, like all humans, think linearly (in time) and are unsuited to design narratives that have multiple connections. Therefore there remains no alternative but to test each time a part of the system breaks. And after each fix, the extensive testing has to be done again.
In short: Testing (and post test / development changes) are much bigger than the change itself. Unknown issues will take at least 2-3 times the time / effort, and sometimes a lot more, compared to known issues.
That’s is our this month’s story. We started with something that seemed medium complexity; to automatically post stock in hand when material is received from a supplier and book Cost of Goods Sold on shipment to the customer. As soon as we started, the network effects kicked in. Some poor code we write in the tax calculation did not allow us to update the correct valuation automatically and we just got sucked into the quicksand from there. This is explain in Anand’s presentation.
I merged some long pending UI changes in the current release (pardon the rough editing).
Look forward to your feedback.
