Software Maintenance: the ultimate in knowledge management

At the day job, we talk a lot about Knowledge Management. It is a fantastic term since it means almost anything to anyone. And, since the day job involves coding, there is always bugs to fix, processes to enhance, or data to clean up; in short, a ton of maintenance programming. As every developer, scientist, artist, craftsman, and butcher, baker, and candlestick maker knows, it is much more fun to start from the beginning than jump into the middle and make it right. So, to try to make maintenance programming “glamorous”, I’d suggest calling software Maintenance, “Knowledge Management”.

I know so some this sounds like the old, “he’s not a garbage man, he’s a sanitation engineer” statement, but this is more that just a euphuism. Most of what maintaining a mature program involves is more along the lines of evolving the program, compared to just fixing the bone-headed copy and paste errors made by your predecessor the Monday after the super bowl (See Myth #5).

Maintenance programs and projects are not for the weak, mediocre, or newbie programmer. In the extreme case, you need a team of people that know so much, they may not actually exist. The case in point is CADE – part of the U.S. Internal Revenue Service Modernization program. This project’s goal is basically to take the program used to manage the “Master File” which holds all of us and what we owe and paid in taxes, and “modernize” it.
A couple quick points:

1. the program from the 60s that does this has worked for over 40 years, so is it really broken?
2. attempts to ‘modernize’ have been foiled by the complexity of the system. For a quick low down on CADE see CIO’s article, “For the IRS There's No EZ Fix”. It’s from 2004, but I am looking for a more updated look at this.

The bottom line is CADE and programs worldwide do not need to be “fixed” but rather enhanced. And for that, you need people who know two very elusive pieces of information. What ‘it’ does, and what ‘it’ should do.

So where do I start with my planetary goal of re-labeling what I do for a living? With that planetary knowledge base known as Wikipedia. There are a lot of facts in this body of work and by the very nature of how Wikipedia works, it represents the generally accepted knowledge of, well, everything. (Perhaps Wikipedia is the HHTG, internet edition?). The ever-knowing wikipedia starts the KM page something like:

Knowledge Management refers to a range of practices used by organizations to
identify, create, represent, and distribute knowledge for reuse, awareness, and
learning across the organizations.

How many times a day do we hear things like, “well, that is how the system works”, or, “I don’t know, let’s go ask the developers to see what should happen…”. Increasingly, the information (data), and the way our companies use information is being encoded into programs that perhaps only a handful of people can understand? Computers and their programs are great manifestations of reality; it may not be super-intelligent, but it does *exactly* what it is told to do. In that sense, reality is for many aspects of the world, captured, codified, and represented in computer programs.

I am not one of those weirdos that thinks that programming languages are "true" languages, and that anything expressed or done by people can be done by a program. But there is an ever increasing set of problems, and things people do that computers can do or at the very least help do. I believe that the true Knowledge Management is knowing what to leave to the computers, and what to leave to the people. I would never use a person to add up and re-calculate my budget, but i also would never trust a "build vs. buy" decision to a computer.

A measure of knowledge could then be what is understood enough to unambigously encode so a computer can execute the process defined. Procedures, decisions, and the like that cannot or should not be handed off represent "new" knowledge, and worthy of exploration by our infinite minds. The question then becomes how as a society can we trust our maintence programmers enough to not worry or mistrust "The Computer".

What is notable (to at least me), is that the best programs I have experienced contain some level of abstraction that fits well into what the program does. This seems to be the key to our brains. I can type and know that the letter I pressed accurately appears on my screen. I don’t worry about how or why, or how else the same process or event can be cleverly reused; I just worry about pressing the next letter. Same in a program, if a program needs a sorted list of people by name, it should be able to sort, quickly, accurately, and efficiently and not worry about what other piece of someone’s online identity is associated with their name, or when the list will be used, or where the list came from, or why it needs to be sorted.

It’s an oversimplification to say, “divide and conquer”. Some things (such as the IRS tax code) are complex and splitting beyond the atom may make simple pieces, but the knowledge to recombine them usually outweighs using the atoms as-is. The choice to divide and conquer, or to conquer as-is is definitely a management decision. The problem is how do they get the knowledge to make the right decision?