This is the first of many blogs addressing commonly perpetuated IT myths. As an IT professional and academic for about 40+ years I have heard many myths about the IT industry. These include erroneous statements about computing hardware, operating systems, software applications, middleware, system utilities, products, services, tools, techniques, theories and principles. I often bristle (think fingers across the chalkboard here), and when I hear IT issues misrepresented I respond, “seriously?” When seasoned IT professionals make statements about this industry that are unfounded or lacking in substance, it requires someone to call them on it, that is, to set the record straight. So instead of calling these misconceptions lies which would imply malice; I give the perpetrators the benefit of the doubt and simply coin these often over-hyped, misleading, half-truths or downright incorrect statements - IT myths. But let’s leave the myth business to the ancient Greeks and Romans and all others please just bring the facts. Let’s not be misled again with another hysterical, planes falling from the sky, Y2K debacle.

In the recent article, “Brain drain: Where Cobol^[i] systems go from here,” by Robert L. Mitchell^[ii], Mitchell tries to convince his readers that in a few years there will be a substantial number of Cobol programmers retiring and with these retirements will be a corresponding reduction institutional knowledge. The premise is that the applications built with Cobol are the encapsulation of the organization’s critical business rules and that these programmers know how to interpret these rules, where these rules are located and how to modify them. Essentially, what all good programmers should already know how to do. I agree program code is the crystallization of the organization’s business rules and that programmers have a great deal of institutional knowledge. But I assert if this is true for Cobol programs and programmers then it must also be true for non-Cobol programs and programmers as well. So let’s get back to the retirement issue.

The US Census Department and Department of Labor^[iii] have published reports on the looming tsunami of baby boomer retirements; however, the expected number of retirements has been revised steadily downward as baby boomers continue to work longer than initially projected. This downward trend may be attributed to the recent economic recession causing those of retirement age to delay their retirements for financial reasons. This; however, doesn’t change the facts. There is no question in my mind that baby boomers (78 million Americans born between 1946 and 1964[iv]) will eventually be aging out of the workforce and to no surprise many of them are valuable knowledge workers who will leave their place of employment with significant institutional knowledge. So I see no reason why fully competent Cobol programmers would be any different.

As you reflect on this problem, the loss of instructional knowledge through retirements, you might wonder how organizations with knowledge workers plan mitigate it. In Mitchell’s article some of the executives interviewed have tried to build a case that the loss of institutional knowledge is tied directly to the tool set (i.e. Cobol) used by the knowledge workers to do their job. In Mitchell’s article many of those interviewed suggested that the solution is to simply change tools. In this case, retire Cobol and use a different programming language, because the retiring employees will be taking knowledge with them when they leave. Excuse me; did understand this correctly? Retire the tool because the employees are retiring? This solution sounds like a familiar “bathing” expression. Let’s call this solution the “Baby and the Bath Water.” Let’s apply this solution to our loss of institutional knowledge problem. If a number of computer programmers leave their employer, let’s throw out all of the programs and all programming languages that these employees have ever used. Then, let’s rewrite all of the programs in a different language. So the net result is: the knowledge workers are gone, the institutional knowledge they contain is gone and the tools they used are gone. And did anyone consider the financial impact of this approach? Hum, I haven’t quite figured out how this is a good business decision; but I suppose it is one possible solution.

Just to be fair, let’s test our “Baby and the Bath Water” solution again to be sure we understand it; and let’s apply it consistently to a similar problem. In this example, let’s say knowledge worker, Dave D, for many years has been building Excel spreadsheets to do his job and so have the other financial analysts in Dave D’s department. Over time the financial analysts could have built thousands of spreadsheets. It is easy to argue that hundreds of complex spreadsheets can contain thousands of business rules. So do Dave D and his colleagues have institutional knowledge? I think so. But Dave D and his colleagues are all baby boomers and it is predicted they will be retiring over the next few years. Apply our “Baby and the Bath Water” solution and voila! We throw out all of these legacy spreadsheets, as well as, the tool used to build them, Microsoft Excel. Then we hire all new financial analysts to replace the retiring employees and instruct them to build all new spreadsheets in Open Office Calc. So do you think this knowledge management problem is solved? Or are there other alternatives not yet explored? How might a knowledge management solution be more appropriately applied here?

In Part II of this series we will continue to explore this “Baby and the Bath Water” mentality as a way to help managers recognize the key differences between tools from techniques; problems from symptoms; and design from implementation. Stay tuned.     

Tell us your thoughts in the comments section!

Dave Dischiave is a professor at Syracuse University’s School of Information Studies and the Director of the Global Enterprise Technologies Programs. His areas of interest are in large scale systems development and integration and the development and use of large data structures.