Why is good software so hard to write?

Hello all!

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.