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.
Other projects are completely dark from the beginning. Such is the case when you’re building from scratch or your creation has to integrate with an item that has little or no documentation, or it relies on legacy systems or noncomputing elements for success.
An example might be constructing a type of service that is married to a hardware sensor array. You have more visibility if the sensor array already exists, but if the sensor array is developed anew for the project, then all bets are off. If you have to interact with a legacy system, you’d better hope to have all the documentation or other resources that detail precisely how the system operates.
You also better hope that the method you plan to use works the first time; if you run into a blocker after investing days or weeks, you’re right back at the drawing board. Ultimately in these situations, all you can do is throw a dart and hope for the best.
Full disclosure: I’ve often felt the urge to cut off a spiraling discussion on time requirements and say, “It’ll only take an hour,” because I knew exactly what needed to be done and exactly how to do it. Inevitably, it took longer due to a tangential issue that wasn’t visible at the outset. No one is immune to these errors -- we tend to pad too much or too little, or to vacillate between the two extremes.
The old adage of “underpromise and overdeliver” is perfectly apt and too often ignored, but the corollary of “within reason” is usually missed entirely. As with many situations in life, a dose of common sense goes a long way. Those who can navigate these waters are the ones who tend to deliver success again and again -- which can ultimately be problematic in itself. But that’s a story for another day.