Before I go there, I want to detour slightly into some light theory. The most fundamental principle of the science in computer science could probably be stated this way: Don’t repeat yourself.

Its the principle of parsimony and Occam’s razor. Programmers quickly gain the skill of slapping repeated code chunks into one place and making it a subroutine – otherwise you don’t get out of Coding 101. In Computer Softese, this activity is known as factoring, or in the case of data, normalization. It all comes down to the same basic concept.

However, the kinds of stuff that typically gets factored is the behavior code – the code that does stuff – actions, operations etc. So what other kind of code is there? To quote our President, there is the “decider” code.

Strung throughout the “Actions” in the software are the conditional statements that evaluate the state of the nation and choose a codepath for the instruction pointer to travel. This decider code is the true nervous system for software – it continually tests its environment and activates appropriate activity in response to what it discovers. To put it another way, this conditional logic is the “brains” of software – the rest, the activity code – is the “brawn”.

Underlying the actual code is the logical “idea” of what the software should be doing – the experience it is really trying to deliver. This abstract ideal is, in fact, the most critical part because it is the actual point of the whole endeavour. But this fact remains obscure due to its format – a bunch of Boolean tests strung throughout the code each heading up a lot of code branches. So despite its primary importance as the most critical part of our software, it remains the portion that no one actually tries to normalize – that is apply computer science to!

We can describe this logical idea of the software as its set of “modes”. The Boolean conditionals are actually testing the raw data of the system to discover what mode the software is in, and then doing some activity based on that discovery. This is all fine. The problem emerges, the denormalization that is, when these same tests are done over and over again throughout the codebase. How can this happen? By being the typical and simplest (but not best) way to build out an API. And it is almost mandated in a complex, multilevel object-oriented class.

I’ll pick up on that next time.

As you can tell, this is my first entry in my brand spanking new blog. Very exciting! I hope to make this thing look nice eventually, so pardon the appearance till I get my chops with this interface.

This blog is dedicated to an ongoing discussion regarding a new approach to creating software that I have been working on for the better part of a decade. I had no idea that I would be out promoting it one day – I simply was emersed in a professional crisis and had to get some clarity on a problem set fast. The solution I found to my problem has defined my professional thinking over the past eight years, and especially the last six months as I have worked through some remaining challenges to arrive at what I feel is an equally elegant and powerful approach to crafting software.

I will soon be launching my website which will be the hub of activity in the known universe for Cogiton (caa-ji-taan, that is) related resources. Until my designer gets back to me with where the furniture is supposed to go, I’m getting started here as a direct outlet for these ideas.

First I want to delve into what I consider one of the most perplexing issues of my industry – is software programming really software engineering? I thought the wikipedia.org article on the topic had some interesting insight. I especially liked the section on “who is a software engineer?” Pete McBreen seems to argue that engineering is not descriptive of what programmers really do, and I tend to agree. His article on software craftsmanship I think gets it right – our industry is like a Medieval guild full of artists rather than modern engineers.

The reason for this, in my opinion, is not endemic to the profession, but the approach. In other engineering disciplines, practitioners use math and models to design systems that have parts and pieces that are somehow quantifiable and manipulable. In contrast, the fundamental organizational unit of software today, the object-oriented class, has all the organizational integrity and mathematical rigor of a big plate of spaghetti. You never know what kind of tangle is in one.

Despite most good efforts, developers typically start with a method on a class and just start hacking in some behavior. As long as it stays simple, things are usually reasonably clear. As more and more “modes” are added to the class, each method becomes increasingly contorted by conditional branches – basically exceptions to the general behavior of the class. With object-oriented inheritance, additional complexity is introduced as each class in the inheritance chain can have its own “modes”, and these need to be made to work together. Rarely do you see classes extended over three deep. Why? Because this mechanism for behavioral inheritance is actually pretty bad. Don’t get me wrong – inheritance of behavior is a good thing. Just using chained classes has proved be be a very problematic way to achieve this goal. And there is another way.

In my next entry, I’ll start to go into some more detail. And by the way, all of this initial discussion, until somebody starts writing back (nudge, nudge) , will basically follow the lines of the on-line book I’ll be putting out soon.