A recent study of IT executives by McKinsey showed that executives’ top three concerns boil down to costs. They believe they can cut costs and improve the efficiency of IT by using lean principles, increasing the use of offshoring, and by scoping projects down.
While reducing business functionality of the projects is one way to achieve this, it’s not considered optimal. The better way to achieve success is by reducing wasted development effort. The challenge is to achieve these efficiencies in a climate where project complexity is growing exponentially.
Bill Curtis, senior vice President and chief scientist for CAST Software, said that successful application of lean principles to development and maintenance can significantly reduce complexity and cut costs. He notes that as much as 40% of a project’s cost is potentially waste. He points to 30 years of data showing that in less-mature IT organizations, anywhere between 30% and 50% of time on projects is spent fixing mistakes.
To effectively apply the principles of lean, however, IT must measure the detailed structural aspects of the product itself, like security, robustness, maintainability and performance efficiency, as well as other attributes. These factors determine the cost of doing work on the application and the risk that the application presents to the business. Unfortunately, most of the time, IT measures other factors like size, requirements, and function points at a higher level.
According to Curtis, most of the problems lie in the interactions between different tiers and different languages within the application. In other words, component quality is different than application quality.
Curtis described the landscape this way: “Most developers know one or two languages. Let’s say I’m a really good Java guy who knows how to write tight, elegant Java code. The challenge for me is that that business logic sits within a much larger body of technology that forms the application.
“There’s the UI tier that may be in ASP, JSP, VB; there’s a data management tier that may be in enterprise Java Beans or Hibernate, and SQL queries bouncing back and forth between my logic and the data. I may have to interact with middleware, enterprise apps that may be in SAP or Seybold, and I may even have to go off to some legacy app that’s in COBOL. Now, I’m a great Java programmer, but when I was in school, COBOL was taught in the archeology department.
“Any one programmer can know a lot, but no one can know everything.”