How hard should work be?

Work is called work for a reason I suppose, but it seems like there is a line between work and self-punishment. I was recently reflecting on my grandfather's career (since he recently passed away). One key event struck a chord. My grandfather left the Midwest town of Oxford, IN to become a radio operator on a ship. He studied, traveled down to New Orleans and every week put on a clean shirt and went down to apply for a position as a radio man. It took a long time to land that position, eating through his meager savings, and relying on the charity of his brothers to make it through. But once he was on a crew, he recalled great times and adventures sailing up and down the Caribbean and west Atlantic. Sure the conditions on board were not ideal, and the hours long, the work tedious, but the years flew by.

I am sure that no one in the IT work-a-day world sees their job as an adventure, but surely there must be more than a 9-5 day and a paycheck right?

Challenges abound at my day job with Learn.net including getting a new exciting release out, keeping new bugs out as old bugs are squashed, and trying to support a new web marketing push. The thing I think is missing is the satisfaction of a string of wins which would lead to momentum.

From a development side we are doing great - migrated to Bugzilla and use their XML-RPC interface to automatically track exceptions that occur. We now use container managed authentication with JBoss to secure our application. Customization will be easier too since we started using Velocity template engine. This is nice since we can continue to use java objects, but do not need to deploy changes to templates, and our customers don't need to learn JSP.

All we need to do get marketing on track and its off to the races!

Practical Knowledge

Ever since the Planet of the Apes, we all identify with the "Knowledge Imperative". I am not talking about the smooth talk of a KM salesman , I am talking about the primitive drive in each one of us to know stuff. This imperative ranks right up there with procreating in the human psyche - the need to not "un-know" anything. Heaven forbid we forget how to make electricity (we can always look it up on Google, right?), or find the roots of a polynomial, or something as mundane as balancing a checkbook. Business organizations are the same way. The organizational memory is vast and ingrained in the organization. Much in the same way the human memory is safely contained in the inside our own body, I am skeptical that a process or practice can be developed and implemented that can extract and capture all that is known and keep it accessible and useful. (It’s a well known fact that a fact that falls in a forest makes no sound).

Ray Kurzweil in his future looking book The Singularity is Near, makes a compelling argument that the capability of technology will continue to grow at its continue exponential rate and be comparable to the human mind’s capability for processing in the near future. When this happens, machines will become both inseparable and indistinguishable from people. While I am a big fan of the Singularity, I am still skeptical that we as a people know enough about how knowledge management works in practice.

a priori knowledge is the measuring stick I will use to measure when machine (assisted) learning will transcend biology. This mysterious set of things we just know. There is no citation, no class, no documentation on these things; we just Know them and take them for granted.

In any job or situation in life there are things that are known from experience. Jargon, technique, stylistic approaches are all learned, but at some point they become second nature. For that set of people one could argue that the knowledge from these experiences has become a priori. Some a priori knowledge is truly that, “known before experience” breathing? We all breathe? Anyone ever read a book or took a class on breathing (other than pregnant women, the will be the first to tell you that pregnancy makes you forget…but that is another story). What about walking? We all started as sub-performers in the bipedal transportation area, but most of us can walk without even thinking about it. Could the same be true for things at work? If programmers are learning a new language, or technology, we don’t start at the beginning; we start at some common point of common knowledge.

Is there a substitute for this second nature knowledge? Not a chance. Would you go to a surgeon fresh out of med school or one that is in her prime? Experience is invaluable. You can’t teach experience and therefore, you can’t teach a priori knowledge.

It is learned. It's not what you know - but what you can know.

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?