Legacy thinking is giving rise to a generation of applications that are obsolete before they're even out of development. It's time for IT shops to get serious about architecture and system design, and say goodbye to the "duct tape and spit" approach forever.

Every year, world-renowned debugging expert John Robbins,founder of US consultancy Wintellect, spends vast amounts of time consulting, training and debugging for .Net applications of all kinds. One of the most common problems he and his team see in the debugging side of the business, which includes performance tuning, is developers, especially those in IT shops, stuck in the "VB form" mind-set. For years such developers have been doing one-off Visual Basic 6.0 client applications but are now thrust into the wild world of big server programming. Because the rules and techniques for server applications are so radically different, this mind-set inevitably leads to application designs that are "buggy" and do not scale.

"Many times in our debugging business we've gone into a company to work on a problem - especially performance and scalability problems - and we quickly see the problem emanates from the original architecture," Robbins says. "In those cases, that indicates a fundamental thinking problem. In today's world of ASP, .Net and server-based applications, if the developers don't have experience in those server applications, they 'bring what they know' to the architecture, which is definitely legacy thinking.

"The legacy thinking is, unfortunately, prevalent in IT shops in our experience. The majority of those developers targeting Windows have spent the last 10 years focused on writing client applications. The productivity of those developers has been incredible and they have definitely contributed to the bottom line of their organizations. However, there's a huge difference in a client application and a server-based application, and that's the problem . . . We've seen some applications that are version 1.0 development become legacy applications immediately upon release because they have been architected with the 'duct tape and spit' approach."

What Robbins is seeing writ large is a problem Australian IT blogger Paul Reedman identified last year after some maddening experiences of his own.

"There is a problem within IT organizations which I believe is far more serious than legacy systems. I call this problem legacy thinking," Reedman, a 20-year veteran of the IT industry and member of the Queensland Executive Committee for the Australian Computer Society, wrote in his ITToolbox blog last year. "It's a thinking which has not been influenced by the new technologies (Java, .Net and SOA). It's a thinking which is trapped in technologies which were popular 10 to 15 years ago.

"This form of thinking is a problem because it can influence an enterprise IT architecture and a system design. Sometimes this thinking is a result of a lack of education, which means a solid dose of training can usually reform the thinker. In other cases the thinker appears impervious to any change and holds on to the ideas and thoughts which were fashionable a decade ago.

"Maybe I am being harsh, but I suspect that if you search your IT workplace you will find numerous examples of legacy thinking."

The blog entry, inspired by Reedman's own frustrations in getting some developers, particularly those from a Cobol background, to understand the technologies behind a new type of platform his organization was trying to implement, won fairly universal agreement from blog readers. Reedman says that although some of those developers he was working with at the time were able to make the leap and understand the new environments and others could do so with a little training, plenty more continued to find the whole notion very difficult. The age of the programmers concerned was apparently not a factor.

"There were some [developers] who were able to make the leap and understand how componentization works, how Java works, and then some of them were trained, but others found it very difficult. It was very difficult to make them understand the new way of the service-orientated architecture, how services work et cetera.

"I remember there was a Meta Group research [Meta Group has been acquired by Gartner] where they found [with developers] a third could take on the new technology straight away, a third will take it on after some training, and a third won't take it on at all," Reedman says.

His own experience seems to reinforce that finding.