I had a professor in my software engineering program at UT who said that “Code is the desiccated relic of a long intellectual process.” I have never heard it put better. I am a big believer in the “Say it in code” principle - that your code should be simple and readable enough for others to understand (or at least yourself when you look at it again a year later and wonder “Who wrote that mess?”). Experience tells me this is not sufficient. Object-Oriented Analysis, Design, & Programming (OOA,OOD,OOP,OOAD,OOADP, or OOADD for those with short attention spans) has proven itself to me as the best available technique for maintaining the original intent behind code - after all, the behaviors and the state live together in modules that encompass a domain concept - if we have done our jobs.
OOADP also gives us more tools in our toolboxes for tackling complexity problems - if you look at the classic Object Oriented Analysis you can see that while functional, procedural, and data-flow techniques are suitable for certain classes of problems, an OOADP approach encompasses those and adds flexibility - especially in complex interactions of part-whole, is_a, has_a, and acts_like_a domain relationships.
By the way - the most under-read book on OOP is Streamlined Object Modeling.
Streamlined gets us the rest of the way there on being able to look at a system years later and understand what is going on. The appropriately-named DIAPER process “catches all the crap” and the whole book presents a dozen patterns (most of you probably think of these as analysis patterns) based on about a hundred principles - along with sample code for Java and Smalltalk.
I think the beauty of Streamlined is that by taking some decisions away (constraining our design and coding to the dozen patterns), we are freed to focus on the problem domain. It helps by reducing the arbitrary complexity that Brooks bemoans in The Mythical Man Month - because when you go look at a Streamlined object you know where to find stuff and you can quickly grasp how it interacts with other objects to get the job done.
And all is well with the world. Well, not quite. You see, in the real world these days - even if you are cool like us and write Ruby on Rails Web Applications - most of your system state resides in a relational database. Sigh. The Object Relational Mapping problem has served as some great fodder for theses and dissertations - not to mention lots of consulting dollars. Because at the end of the day all of that extra power I was bragging about object-think having over data-flow or functional or procedural or whatever older programming technique your technology stack forced upon you - all of that gets diced to shreds when you start to bolt your system onto the relational database.
Inheritance is a problem for databases. Single-Table or Multi-Table - you want to be able to collect, select, inject on your sets of objects without doing an 8-way-join? Sorry. Cost of doing business. Cache your app like mad and keep going.
OK. That works fine for toy apps. And I good-naturedly include any app where the domain complexity does not overwhelm the technical issues - even if you are generating a billion hits-per-second or whatever you lucky dogs are doing these days ;) no jealousy at all there friends!
What I am trying to get at here is that even with a powerful abstraction like Active Record (see Martin Fowler’s book Patterns of Enterprise Application Architecture for the general case and Ruby on Rails for an incredible implementation) - any time we have to think about the fact that there is a database under there it detracts from the ability of the development team to maintain momentum on new features and the evolution of the system as a whole.
The nature of a business application is to change - I cannot recall the name of the classic paper - but business apps were categorized a long time ago as a system which is not simply simulating the world - it simulates some things sure - but it also changes the world as soon as it is released. A good business application provides the business with capabilities it did not have before. And as soon as a business has new capabilities it will capitalize on them - you guessed it - there will be immense pressure to change the system to provide new capabilites built upon those just created.
That is a good summary I think of why software is a lucrative field and why thinking practicioners of the software art need never fear running out of cool work to do. Each time we innovate for our customers or our employers (they are our customers too after all) - every time a new system leaves the abnormal state of the lab and starts breathing in the real world, it better be solving some key business problem. Then those customers are going to look around and say “Wow! If we can do this, then what about …”.
So we need to stay fast and agile - ready to respond to those wonderful changing business requirements that let us know the system is still alive and still being used to do stuff. And a relational database makes that problem a little harder.
Am I just ranting? Mostly. But there is hope for us OO purists. Seaside can run on Gemstone - an object store that persists state across servers and on disk (the way most of us use the database) without having to wrestle with the ORM problem. And I have long had a desire to really learn the Smalltalk way of doing things - but so far I have not gotten around to it. So what really melts my butter these days is Maglev - a project to make the Gemstone architecture support Ruby (or a project to make Ruby run on the Gemstone architecture if you like).
It bugs me that the Rails community is not talking about it more of late - my impression is that since it is not open and free (yes, Gemstone is made by a real company and they stubbornly wish to keep the system proprietary) that the community wants to ignore it. I have been scouring the web for press on the RubyConf2008 talk about Maglev, and I have found only a couple of tweets! I am waiting with bated breath for Confreaks to release their videos so I can finally see what I missed.
I think we can at least talk about the technology. Gemstone does have a free license for many classes of application. And for those of us with big systems like mytoons.com - we’ll just have to negotiate :)
Finally a little encouragement to the Maglev team themselves - lets get some blogs going and an alpha or a beta out there to experiment with. I am ready to turn ActiveRecord into a no-op! Well, at least an abstraction where I don’t have to worry about inadvertantly introducing a database crippling query into the mix by asking my object model an interesting question. Cheers for turtles all the way down!
