Skip to main content

Chickens and Eggs - Methodology and Tools

Posted by johnreynolds on October 15, 2008 at 7:33 AM PDT

Which came first? Object Oriented Methodology or Object Oriented Languages?

From where I was standing at the time I'd have to say Object Oriented Methodology. Our practical experience with software led us to value encapsulation, inheritance and polymorphism - but we didn't have to tools to enforce those concepts in our code. End result: We knew how to write good code but it was awfully hard. We had to hand-craft coding conventions that Object Oriented Languages gave us for free.
Object Oriented Languages led to a Renaissance in programming... The tools codified the methodology - leading to unquestioned validation of the methodology - leading to wide adoption of the methodology. Said another way: Most programmers began to think in terms of Objects.
Methodology by itself probably would not have led most programmers to think in terms of Objects. Languages by themselves probably would not have led most programmers to think in terms of Objects - If you don't believe me go back and look at most of the C++ code that was written in the early 90s (most programmers continued thinkin in C for several years).
Object Oriented Design and Object Oriented Languages have been a huge factor in my programming career - but they aren't enough. Objects are just a subset of what I need to solve the problems that I have been asked to solve. I deal with Processes and I deal with Services.
Processes and Services are hand in glove - Processes Orchestrate and Choreograph Services - so any good Process Tool has got to also be a good Service Tool.
There are some really good Process and Service Tools out there - but they're mostly proprietary (expensive). Those of use who are fortunate enough to use them have really been able to immerse ourselves in the methodologies - We think in Processes and Services.
Most of the widely available Process and Service Tools feel a lot like C++ to me... They're Object Oriented environments that have "just enough" Process and Service tacked on to be useful - Many folks who use these tools still mostly think in Objects.
It's hard for me to convey exactly what I am talking about - unless you yourself think in Processes and Services you probably won't grok the nuances that make them powerful - but here's a stab at something that you might be familiar with.
The Spring Framework has a very good component (Spring Web Flow) for controlling the flow between web pages that are presented to a user. If you're a Process guy like me, this is a wonderful little subset of what's available via BPMN. You are essentially modelling a Process with a single participant as they navigate through a series of screens.
Unfortunately, the IDEs that support Spring Web Flow pretty much shuffle it off to the side. They encourage good old OOD with this funky little XML thingy that you use to govern page flow.
A Process Oriented IDE would turn this paradigm on its head - When you started a new project you would begin with the Web Flow. Your Pages would begin life as stubs with just enough functionality to set the data the Flow Controller needs to get to the next Page. Instead of a "folder tree view" of class hierarchies, you'd find the elements of your project by drilling down through the Flow diagram to the Pages and the underlying Services (objects) that support those Pages.
What I've described is pretty much what you'll find in the top-tier BPM products... Use these tools and you'll quickly start thinking in Processes and Services.
Once again this reminds me of the early days of OO - Smalltalk was impractical for most of us, so we had to make due with C++. The mainstream programming tools were still procedural (rather than object) in flavor... but in just a few years the critical mass of programmers started thinking in Objects. The rest is history.
My guess is that Process Methodology and Tools are at about the same point where OO Methodology and Tools were in the early 90s... What do you think?
Related Topics >>


John, I would suggest in your response on October 16th that, perhaps at the risk of stretching the definitions a little, you've confused Methodology with Paradigm. Paradigm frames your world view, and is the box out of which one is supposed to thing. Methodology is a process and collection of artifacts used to communicate the What. Certainly the Paradigm precedes either the Language or the Methodology, but I don't think Language or Methodology necessarily must occur in a given order.

rehagur - I'm betting that when you first saw C++ you immediately said something like "Finally!". Those of us who had been using C immediately groked why we'd need objects - because we'd been implementing the same constructs in our applications for years. That's what I mean about methodology preceding the language... we were already starting to think in objects - we just didn't have a language that made it easy to code in objects. -JohnR

I know this isn't the point of the blog, but it's very validating to hear someone else that likes to approach it top down with SWF. After I got to know the guts of it I really expected it to turn the web development world on its head.. Instead, it's been pretty much ignored in the face of enhanced ease of development with JPA/EJB blah. I guess the reason being people are usually coding more data access than complex process flow...

Ah.... the good old days. From where I was, in 1986, it appeared that OO languages came first. When we started with C++ the only reference on OO programming was the Smalltalk code base. The abundance of OO methodologies (most of which didn't grok OO programming) didn't come about until the early 90's.

As someone pointed out on my other blog... Sketchpad was clearly an Object Oriented application (in its architecture) and it preceded Simula. I'll go out on a limb and say that Methodology always comes first... We build tools to help us build things better... and better is usually a better methodology. The key is that they can't stand alone. If you use an OO Language wrong (with the wrong methodology) you'll fail. If you try to use a methodology with the wrong tools (let's say Agile with a tool that takes forever to compile) then you'll also fail. The sweet spot is when your tools and methodologies align. -JohnR

It seems to me that in this case we can answer the question: a specific language came first, namely Simula67.