I recently read a report of a new canal (yes, a canal) planned by British Waterways between Bedford and Milton Keynes. If the plan goes ahead, it will be the first canal built in this country since 1894. The construction industry has experienced massive improvements in every aspect of its work since then, yet this canal is expected to cost more in real terms than when it was first mooted in 1801, and to take just as long to build.
This would seem to be a case where some natural law is at play - human gestation still takes nine months, however many men you put on the job. If the same applies to IT, how do we meet the current holy grail of reduced time to market?
The answer, I think, lies in the earliest spectacular success of software development: its role in the Apollo 11 landing on the moon. That success was due in no small part to the practice of freezing code, when it had been proved to work, from the earlier Mercury and Gemini projects.
The current fixation with time to market is not new, although the same problem has been described in other ways ever since IT started to become important. The terminology has changed but, unfortunately for business, the underlying reality hasn't.
From the late 1960s to the 1980s, the holy grail was programmer productivity. The perceived need was to produce programs faster because that implied lower cost and the cost of producing programs was hurting business. Since then, the driver has been to implement programs that promise market advantage before competitors do. The incentive is different but the direction of effort is the same: produce programs faster.
In the interim we had higher-level languages, such as 4GLs, Case tools, developments in DBMSs, studies on programmer productivity (such as Thadhani at IBM on response times), RAD and much else. All these developments were trumpeted at the time as heralding a new era of fast, effective production of programs. We have also had quasi-religious debates on the various technologies involved, of which OO with its promise of re-usable components is merely the latest.
But the truth, I suspect, is that while each new technology brings some improvement, the time to produce a working program now is not significantly different from that required in the late 1960s. Only a comprehensive approach, ensuring gains in all processes from requirements definition to roll-out could achieve that. Even then, the investment cost required might entirely negate any possible gain.
So the answer to the time-to-market problem, I believe, lies in asking yourself how little code you need to change in order to meet new requirements. And the direction of IT development strategy should therefore be to position IT systems so that, when changes are needed in the business, as few new programs as possible have to be developed. Legacy is good!