It's not the Code, Stupid (Part 2)

Maybe "lie" is too strong a word -- it's just a simplification. As I pointed out a month or two ago in my "It's not the Code, Stupid" article, when you're on a software team, sometimes the most valuable thing you can do for the Product Owner is tell him he's smokin' crack. Dude -- you're not getting a program. At least not for $20 and a 4-hour iteration time you're not. Not a program that computes the average life expectancy of Swedish Llamas.

It's perceived value to the check-writer that we provide. Some times that value is in the form of code. Many times, especially in large organizations, it's not.

Another good example -- why are there so many "gates" in software development? Two reasons: first is we don't trust the teams. The Agile-listas get that one. What's the second? That the organization has to come to learn and understand what the technology is supposed to do. That has nothing to do with trusting the teams or how fast code can be slung -- it's all about how fast people can learn and change their ways. That helping the organization change -- it's as valuable (or more valuable) than any software anybody could ever write. As proof? There's a lot of companies dying for lack of software that exists on the store shelf ready to purchase. But the organization won't let itself be saved.

I was talking to a friend at work the other day and we were talking about agile projects (The subject comes up a lot since I am an agile coach currently). As I left, it occurred to me that our conversation was all in terms of programming. How do we help the developers write code. But heck! Programming is not what successful technology projects are all about!

Take this guy -- he built an entire 3-D renderer using Microsoft Excel. Let's assume someday that you can create major, valuable change in your organization using a totally graphical environment -- executable UML, workflow engines, meta-object configuration engines, etc. Heck, most of this stuff is already out there and people are already creating solutions like that. Would you measure progress in such a case by lines of code created? As the Excel guy points out, there is no code.

Successful projects provide value to the check-writer in iterative, incremental chunks. The value is in the generalization of the principles, not the principles themselves. So take your Agile Manfesto off the wall, your Barry Manilow records from the shelf, and move up to the next level. It's the 21st century, guys.

Today I had a similar experience. I was talking to another co-worker about how one of the purposes of modeling was to provide an intermediate language for the team and the user to converse in. This is an extremely powerful concept -- but most times it takes many years once an architect starts using OOAD for the lights to go on. In fact, in most cases the light never does go on. With my friend, I believe I could see the little light-bulb light up. Way cool! THAT'S why I love this job.

The neat thing about understanding the whole aspect of modeling as an intermediate language is that is opens up vistas into philosophy that we mere programmers never had before. Here's why: the process of analyzing the behavior and structure of a world or paradigm (to use Kuhn's phrase) by creating an intermediate language is a general-purpose analysis tool. It has nothing to do with programming, coding, technology, or any of that. It's analysis with a big "A".

Thomas Kuhn, who was in the 1956 LP
"Philosophers Gone Wild"

To put this into easier terms, you can and should use the same tools and conversations in a project that develops Excel-based 3-D worlds as you would with one that used C++. It works the same way even if there is no technology developed -- perhaps the end result is that the business buys a COTS product. Heck, it works the same way even if technology is not involved at all.

What is it?
Would you believe we don't know?
Tell me how you use it and I'll tell you what it is

You can use the structure/behavior methodology of analysis to talk about world peace, alien invasions, philosophy, politics, tribal religions -- you name it. Wherever you have people of various expertise coming together with a fuzzy problem that they want to make into solid actions, you can use it. It's like a mechanic waking up one day and realizing that his crescent wrench can also be used as a brain surgery tool and a jet ski -- it's counter-intuitive and at the same time mind-expanding.

Does that mean those tools work all the time? Of course not. But they work enough to be useful. This is because we're combining two traditions of philosophy. The first is the tradition of Plato and Aristotle to take things and break them up into smaller things by looking at their attributes. We ran with old Plato for a long time -- most of western thought is based on categorization. Heck -- all of science is built on it. But then philosophers found a lot of problems with it.

When we categorize something like a "chair", is it the same chair whether it is in a movie theater or a fancy restaurant? The initial thought is to continue to refine the idea of "chair" so that we'll have two new concepts, "movie chair" and "restaurant chair" But that only held the wolves off so long.

BTW, this is exactly the same problem software architects have when we speak of classes in our domain model. Is our concept of "customer" the same as the one the team next door is using? Is there one, great, mightly, all--powerful concept of chair that we then all specialize from? Plato thought so with his concept of forms. Many software and enterprise architects think so also.

What western thought finally realized was that words, ie, language, exists in a context of other words. The words themselves actually have no meaning. It's the context that they appear in that gives them meaning. You can thank Ludwig Wittgenstein for all of that. He started in on the Philosophy of Language. There's a great article here that goes into some of his work, but the water is deep.

Unless one knows how to weave the word into some form of human activity, the saying of the word is not yet language. It is like a break that is not yet connected with the entire mechanism. The parts seem to be there, but it does not yet have the connections to function as it should.

This is the problem we have with "chair" -- we're not talking about it in any context of activity. We add different activities, we get different ideas of "chair". It's also the problem we have with "customer" or "user" or "claim" or any one of a thousand other analysis classes we use everyday to describe the problem domain. The words themselves are nothing, the behavior and structure come together to create the language.

Things are never what you think they are.