I’ve come to believe that there are definite stages that software developers go through when learning a new concept or technology, and you can’t claim to know that concept or technology until you have progressed beyond several of those stages.
You gain the most superficial understanding when you are introduced to something and understand it intellectually. Deeper understanding comes when you begin to see how to meaningfully apply the new thing to your work. When you actually being using the new thing, your understanding becomes very deep, and if you reach the point of actually designing an implementation of the new thing itself, you have reached the deepest level of understanding that most of us can ever hope to achieve–you are now an expert. I think that the only level of understanding I know of beyond that is actually proposing and implementing the next generation of the thing. But maybe there are even more steps beyond that, and I can’t see them because I have only ever, on a few occasions, reached the point of designing an implementation of a concept, and maybe we can probably only know about the very next level that we haven’t yet reached.
I started one of these cycles around 1998, when I began to write Web applications complex enough that I figured that a good idea would be to have all interactions from the browser go through the same block of code that decided how to dispatch each request to the correct handler. After a while, I learned that many people stumbled upon this same idea, and eventually evolved it far beyond the simple conditional logic I was using to the Model-View-Controller (MVC) pattern. I was lucky that I already saw the problem it was trying to solve–I was able to quickly jump from the first level of understanding to the second and progress onto the third. I learned about Struts at some point and immediately began using it. Eventually, I started a project to create a port of Struts in PHP, and I began to achieve some insights I wouldn’t have otherwise, such as the fact that the view layer is much closer to the controller layer than is the model, and the implications this has for the presentation technologies we use. I felt I gained a deep, intuitive understanding of MVC I didn’t previously have.
Sometimes, we never get beyond the first stage of understanding for various reasons. We feel we understand a new concept or technology when its described to us, but we don’t fully understand why we might adopt it or how it might our jobs easier, so we decide based on our intellectual understanding that its not a good idea, when we are least capable of making that judgement. I have missed a few opportunities to learn valuable new tools or approaches earlier because I was unable to move beyond my superficial intellectual understanding of them and the belief that this understanding was adequate.
Recently, I concluded that I had missed an opportunity with REST. I had read about REST in the past and just didn’t reach the stage of understanding its full implications. I probably thought it was something trivial I already knew, and with the increasing use of Web services around the same time, I didn’t pay enough attention.
Luckily, because of my increasing awareness of and belief in the stages one goes through to truly understand a new idea or application thoroughly and intuitively, I have learned to listen to people more carefully and not judge something that’s new to me until I have at least reached the point of actually applying it, and if other people are talking about something enough, I should pay serious attention.
Recently, I found this blog post on REST, which many people seem to be rediscovering recently. It describes the reasoning behind REST and is probably the clearest explanation I have read. I have also been hearing murmurs lately of what appears to be a new idea (to me): resource oriented architecture (ROA), and its relationship to service oriented architecture (SOA). (Interestingly, many of these murmers seem to be coming from the Ruby on Rails (RoR) community.) For a number of years, I have increasingly designed applications around SOA, and have advocated its virtues, so the relationship between SOA and ROA intrigued me.
This IBM DeveloperWorks article quite clearly describes how ROA inhabits the same landscape as SOA. It argues that REST based ROA and SOAP based SOA are different philosophical approaches to developing Web services: ROA focuses on the states of a data model, possibly expressed as a microformat, with client/server interactions based on the standard operations of the REST approach (think database CRUD), while SOA is “activity centered” and based around the more familiar idea of invoking functions. They are different paradigms and either may be appropriate based on the type of application considered. The IBM article very clearly articulates when one approach may be preferrable over the other.
Reflecting on all this, it seems to me that Zope’s approach to user interactions is very compatible with the ROA philosophy. Zope has this idea of acquisition, one of its most unique and powerful ideas, and the one that people have the most difficult time understanding. Even I feel sometimes like I don’t understand it completely, and I consider myself an experienced Zope developer. The way I choose to explain it to myself–and this explanation may be fundamentally inaccurate or at least grossly oversimplified–is that acquisition is essentially inheritance implemented at the object level instead of the class level. Anyway, it allows you to build the different “verbs” or behaviors, views, whatever you want to call them, and you can specify those verbs on the same noun in a consistent way through a URL (without a query string). Just in terms of the addressing approach, Similar schemes can be implemented in Java servlets and other platforms like Django where you have fine grained control of URL mapping, but how many actually do this? (I must admit, that Django’s much vaunted admin interface does look RESTful to my eyes, and together with my re-education about REST may change the way I develop applications on that platform.) Its typical to see one URL mapping for an entire application. But in Zope, that’s just the way things work automagically.
(Zope is an ingenious approach to application development in general, and was probably the first true RAD Web application development framework. Its too bad that with the rise of RoR-esque frameworks like Django and TurboGears, and the probable failure of Zope3–the completely reengineered response to those RoR-esque frameworks–Zope may ultimately become one of those oddities of software history and not get the proper recognition it deserves.)
The application of microformats within ROA is particularly interesting to me. Another thing I have learned over the years, is that when several new ideas converge, something exciting is usually happening. I have reached the stage where I see the practical applications of microformats and have started to use them. Soon, I will begin developing a social application built on Django that will be making use of a microformat, and as I design it, the ROA approach will be on my mind and influencing what I do. This will give me the opportunity to reach the next level of understanding of the concepts mentioned in this post, and I will almost certainly be discussing them more in this forum.
The downside is another lesson of experience; when you learn something new by using it, the application you build will contain all the mistakes produced by learning, and you don’t always get a chance to return and fix those mistakes.