In the decades I've been in deep IT, there have been a few constants in the sea of change. One of those constants is that the simpler solution is generally the better solution. Also, estimating the amount of time any one task will require is a fool's errand.
We've all been in technical meetings where a widget needs to be tweaked, a service needs to be modified, or what have you. Invariably a nontechnical person will state the task can't be hard to do, and an engineer or developer, eyes growing wide, will counter that it will take several days at least. Many times, another techie, perhaps looking to curry favor, will chime in and say it should only take a few hours to work out. The truth is usually somewhere in the middle.
The fact is the nontechie has no frame of reference for the time requirement; he simply does not know if he asked for a frame-off rebuild of a classic car or an exterior wax. The engineer who has to do the work will say double or triple the amount of time he actually believes it will take in order to build in a buffer in case things go pear-shaped. The other techie knows what needs to be done, but fails to consider the commitment required around the actual work itself, such as the time needed to stand up a new dev environment, build test harnesses, perform testing, create documentation, and so forth.
A perfect example of this phenomenon was seen recently from our favorite Martian, John McAfee. Last week he very publicly stated it would take "half an hour" to access the data on an encrypted iPhone. There is absolutely no way this is true. It's a nonsense statement that has less bearing on reality than most of the claims we've heard on the presidential campaign trail this year -- and that's truly saying something.
The truth is there are boatloads of tasks where the meat of the task takes only an hour or two, but the effort required is far greater. Altering a few dozen lines of code to address an issue or to provide an enhancement seems relatively simple, but getting to that point and back out to proven stability is not. As someone once said to me about such a situation, "It's just some typing, right?" Right, it's only typing.
Time estimation in most projects is usually reasonable for the elements of the project that are visible at the time. For some projects, this visibility is end-to-end, such as a specific infrastructure build-out. You know how many servers or instances you need, what software will run on them, how they will connect to various networks, and so forth. There's little ambiguity, and the parts that can't be readily quantified can be easily identified and padded accordingly.
Sign up for CIO Asia eNewsletters.