Tradeoff management key to successful software development techniques
To successfully develop software, tradeoffs must be made in cost, quality and time. Proper tradeoff management results in quality software.
Whether it's a project manager doing software acquisitions or an enterprise architect designing an application, in successful software development, it is important to understand the traditional trade-offs between cost, quality and time. For those who are not familiar with this age-old truism, the general rule for any undertaking is that one can balance any two of them only at the expense of the third.
With all other resources being equal, one can create things faster and cheaper, but quality will suffer. One may also have items created faster and of higher quality, but more often than not the cost will increase. And, finally, with all other factors being equal, when creating cheap, high-quality goods and services, more time will be needed.
It may seem like an obvious point, but like it or not, many successful software developers have discovered that some variation of the 2 out of 3 gambit resonates through just about everything we do.
Several months ago I was asked to assist a large, billion-dollar computer provider with creating training for one of its larger clients. A common enough request, yet in this case the corporation was attempting to dictate cut-rate prices as well as delivery times. Again, while not too unusual, the time and cost constraints were so draconian that anyone with any basic experience with the pick two gambit could see that the company had virtually insured that an inferior product would ultimately be created. I, like many others, respectfully declined their terms. We simply had more profitable ways to spend our time.
Not too surprisingly, six months later the panic calls began. Not only had this would-be training project enraged the larger, multi-billion dollar client, but the materials clearly demonstrated several major conceptual flaws. Moreover, given that the majority of the developers were from cultures that traditionally do not tolerate such things, their first trainer had unfairly been thrown to the wolves.
The effects of this self-imposed, tragic choice of two led to spending more money to fix the project than would have been spent if anyone had bothered to price things properly the first time. Even when tasked to help, citing the project's over-promise and under-deliver problems, other industry-savvy consultants, all of whom were tired of the project manager's penny-pinching and promise-breaking, had understandably distanced themselves. Having consulting, as well as much training experience on their topic de jour, I was given the difficult task of having to talk around the training defects and content deficits.
Successful Software development
While a fool will work for a sage's pay, the reverse is simply not true. The result is that, in talent as well as technology, while great values can indeed be found from time to time, such findings are rare. More often than not, one must eventually face the reality that one invariably gets no more, and certainly no less, than what one pays for.
To put the idea in a slightly different light, an excellent professional project management friend of mine once noted, "If there is money enough to do things over, why is there not enough to do things right?" And if there is not enough money to do things right, there's no point in even embarking upon the project.
It's a hard lesson to learn, but successful project managers and enterprise architects know that when it comes to software development, there are always tradeoffs to be made, and more often than not, those tradeoffs can be evaluated by choosing which of the cost, quality and time trifecta will have to suffer.
