Are you really using Object Oriented Programming, and does it even matter?
This article is bound to be controversial, but I beg you to keep an open mind as you read. I have put a lot of research into this, it is not your standard knee jerk "OOP Sucks" article. In fact, you will find in the end that I will recommend still learning Object Oriented Programming (OOP), if you haven't already.
Here are the main points of my article:
- There is no official OOP definition.
- OOP productivity myth.
- So what? Learn OOP anyway.
OOP Definition
The other day, it occurred to me that there is a lot of controversy in the programming world about what the true definition of OOP is. Many of the given definitions revolve around specific programming languages. Some will say that Smalltalk's syntax is the definition of OOP, others say the same about Java or C++. On the other side of the coin, people like to tear specific languages down for NOT being OOP. I've heard people say ColdFusion is not OOP, PHP is not, Perl is not, etc.But if you look, you can find OOP definitions that have nothing to do with specific programming languages. Here is one definition I found on Wikipedia, "OOP is the act of using 'map' data structures or arrays that can contain functions and pointers to other maps, all with some syntactic and scoping sugar on top. Inheritance can be performed by cloning the maps (sometimes called "prototyping")." That's fine, but here is another Wikipedia quote on the subject, "Attempts to find a consensus definition or theory behind objects have not proven very successful, and often diverge widely. For example, some definitions focus on mental activities, and some on mere program structuring." I think part of the difficulty revolves around deciding which OOP concepts should be included in the definition. For example, some say that true OOP requires interfaces, others say that's rubbish. Also, even the definition of some of these core OOP concepts differs between languages/gurus.
So I ask you this question: How do you even know if you are using OOP? I think this is a real problem. The database industry solved this years ago for their specific problem domain by defining and agreeing on the rules of Database Normalization. So how about it OOP gurus? Why don't you all come together and work out a definition that we can all use? I am not talking about a simple, one size fits all definition (that would never work), but a formalized complex definition, comprising various application types and sizes.
OOP is not more productive than procedural programming.
But lets ignore the OOP definition problem for now and talk about the merits of OOP. Proponents of OOP will tell you that it will make you more productive through code reuse. But has anybody ever sat down and tried to prove this? Yes, they have, and the results will surprise you. Thomas E. Potok, Mladen Vouk, and Andy Rindos published a study in Software – Practice and Experience (Vol. 29, No. 10, pp 833-847, 1999) titled "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" [PDF]. In this study they rigorously examined all of the disparate facets of software projects. They looked at 19 development projects of varying size, some of which involved software being ported between operating systems. The assumption is that porting software by it's nature involves a high degree of code reuse. Their study found that while "the ported products, as expected, have significantly higher productivity than the non-ported projects, there are no obvious [productivity] differences between the procedural and object-oriented products." They looked at project size, developer experience, developer team size, and many other common software project variables. They COULD NOT find any significant productivity increase due to the use of OOP methodology. Instead, they found that "the governing influence may not be the methodology, but the business model imposed through schedule deadlines."One thing Potok et al. noticed that was puzzling was that the larger the project, the more productive the programmers were, regardless of methodology. Why would that be? Their conclusion is that larger projects induce more pressure from management to achieve aggressive deadlines. Therefore, under pressure programmers are more productive (again, regardless of the methodology chosen). That is why they concluded that while "the introduction of object-oriented technology does not appear to hinder overall productivity", the true driving factor of developer productivity was deadlines, and pressure from management.
So what? Learn OOP anyway.
While I am frustrated by the lack of consensus in the OOP community, I still think learning OOP is a worthy goal. I will reiterate that the Potok et al. study notes that while they couldn't find any evidence that OOP is more productive than procedural, they also couldn't find evidence that OOP hinders productivity. So if productivity is your goal, it doesn't matter if you use OOP or procedural. However, there are more factors to consider than productivity.One major factor that would make me learn OOP is it's popularity. I could stick with procedural, but let's face it, it's a dying breed. Most programming jobs showing up on the job boards these days require some OOP experience. And again, there is no harm in using it, so if you want to stay current it's probably a good idea to learn OOP. You can still fall back to procedural now and again if you want to, but having a good solid understanding of OOP will get you far in today's programming world.
Another factor for learning OOP is that modern programming languages are moving more and more in that direction. With each release, ColdFusion has more and more OOP features. Sure, you can still program procedurally, but over time that might become more difficult (especially if you switch to another language).
The last factor I want to highlight is communicating with your fellow programmers. If you want to easily communicate your programming problems and/or ideas to another programmer, and that programmer is used to OOP, it will be much easier if you speak with OOP terms.
Jake Munson
37 Yrs old
I don't even know why we in the CFML community continue to debate things like a clear definition for OOP, whether or not we should learn it, if it's worth the effort, whether or not it's actually more productive, etc., and continue to do so year after year after year. It's a horrendous waste of time and energy.
Let's stop the nonsensical debate--this fight has been won LONG ago--and focus on helping each other learn this stuff through presentations, tutorials, articles, and sample applications instead of wasting time hemming and hawing over whether or not we should learn OOP.
Let me put it another way: if you haven't started learning OOP you're woefully behind the times. So get cracking.
Even though a language like C doesn't do inheritance, polymorphism or encapsulation out of the box, I can apply those principals in a different way within that language. Same goes for ColdFusion, Perl or what ever programming language I'm using.
The 're-use' thing is clearly invented by managers who think that whole applications can be magically 're-used' on a next project failing to understand that the 're-use' we are talking about here often only exists within the scope of the application we're currently building.
Ah well. It's a never ending discussion I guess...
- Luke
I'll agree with Matt - gotta look forward... not back.
Did you read my whole article? I said the exact same thing you said, at the end of my post. In fact, I expounded on it with even more reasons why we should learn OOP.
As far as the first part of the article, I just wanted to set the record straight. Also, I really do think that a consensus on what OOP means would be very helpful to the programming community, just like DB Normalization rules have helped the DBA crowd.
http://www.amazon.com/Object-Technology-Managers-D...
HTH
1) It is 10 years old (at least, the actual date this was written could be well before 1999, the most recent reference in the footnotes is 1997). Further, it mentions nothing about when the actual programs that were examined were actually produced.
2) It only looked at 18 projects, a pathetic sample size.
3) It mentions nothing about what OO languages or techniques were used in this comparison. For all we know, the OO projects were in C++ written by recent college graduates.
4) Their calculation of effort is based on lines of code, a virtually meaningless metric.
At least they were reflective enough to say as much in the actual report: "There are many possible explanations as to why this result has been observed, for example, 1) the observation is not supported by statistical analysis, 2) LOC is an inadequate metric for object-oriented products, 3) the object-oriented methodology was not properly used, 4) more generations of object-oriented projects are needed to see a productivity gain, or 5) there is an underlying factor that is skewing the result for object-oriented products."
Regardless, it seems that: a) OO is no LESS productive than procedural development, and may be more productive, b) OO is the dominant programming paradigm. So my answer to the title of your blog post would be: it definitely matters, at least if you want to continue to be a programmer as your career.
I do agree that a solid definition of OOP is difficult to pin down completely, but I will quote from the brilliant Meilir Page-Jones that OOP involves the following nine software concepts:
Encapsulation
Information and Implementation hiding
State retention
Object identity
Messages
Classes
Inheritance
Polymorphism
Genericity
Not an absolute definition but definitely a starting point that I think just about anyone could agree with.
And they did mention that the developers on the teams were experienced, so they weren't recent college grads. However, you're right about the lines of code metric. But they also went to great lengths to explain that there is no other metric available, so rather than ingore the issue completely (which is what most of us do), they went with the best metric available. I would love to see someone define good metrics for programmer productivity, but as far as I know this doesn't exist today.
And like I said at the end of my post, and in an earlier comment, I DO believe that OOP is very important, if for nothing else than it's the most popular methodology. With this post, I was hoping to expose some of the issues surrounding OOP, but at the same time I tell people that warts and all, OOP is the best choice for programmers.
http://ontap.riaforge.org/blog/index.cfm/2008/11/3...
I think Brian's list is a decent foundation, although I personally wonder about the usefulness of defining a standard in that regard. I suppose there's probably some merit in the idea, but it seems like it would be rather difficult to ferret out and I'm not sure what the cost to benefit ratio would be for achieving that goal of getting consensus. And I think folks who may have considered the task prior might have also not seen the payoff and aborted early for the same reason that most people just avoid the question of having a metric (versus using lines of code).
It is actually possible to have a metric (or several) for a given programming task... the problem with getting that information imo is that there's not currently funding to make it happen.
I think what you would need to produce is an environment in which separate teams (or individuals) are asked to produce a functionally identical application and then compare the results. To keep from tainting the results, you would want to use the same safeguards that are employed in cognitive science, so that it's a truly double-blind experiment.
The application would need to be no larger than would be absolutely necessary to show a key difference between the techniques. The individual programmers (or teams) would need to be tricked into believing that they were working on a production project (and not the experiment they're actually working on). If they knew it was an experiment there are a variety of psychological implications that could alter the results. Those working with OO techniques might be relaxed and casual about their work, confident that the results would indicate productivity while those working with procedural techniques might work harder to prove that their methods are equally as effective. So to avoid that they would all need to be unaware of the experiment. They would also need to be rated for their comfort with procedural and OO techniques (possibly via self-report during the hiring / interview process).
Once the project was completed, a handful of metrics could be derived from the result. The metrics that would interest me most would be "lines saved" (as opposed to "lines of code"). Productivity could then be derived as something like lines of code divided by hours of work, i.e. "does it really make you more productive to save 10 lines of code if you spend more time thinking about the lines you do write?" If in the end you're able to write fewer lines of code and also complete the task in a shorter period of time, then you can say that one was more productive. The results from multiple teams would then need to be averaged for this identical application to get a reasonable cross-section from which you can calculate probabilities and that would give you a solid answer as to the productivity question. When you compare people who say they are say 80% comfortable with OO to others who say they're 80% comfortable with procedural coding, then if there is any notable difference in productivity between OO and procedural, then measurable variance will show where someone who is using a superior technique (where productivity is concerned) will be able to finish the project faster and in fewer lines of code.
http://en.wikipedia.org/wiki/P-value
The problem of course is that, in spite of the fact that an experiment of that nature might actually be valuable to the community as a whole, I'm not sure who would step up to the plate to fund it. I'd love to see it funded though.
Think about how widely misunderstood OOP is even today. There are still very large numbers of developers who think that using classes, or having getters and setters, means one is doing OOP. Now roll that clock back 10 years.
I agree that would be a good way to compare OO to procedural, and I also would love to see someone do this. Maybe I'll do it after I get rich. ;)
@Brian,
You are listing of a bunch of things that should remain static in a good OO productivity study. All of the developers in the study should be on even ground, so the language they use should be irrelevant, and the underlying framework as well. You yourself gave a good listing of terms that should be included in OOP from Meilir Page-Jones. Weren't those concepts around in 1999? When you measure OOP, you should not worry about any factors that are not directly related to OOP. So you could even take a group of programmers skilled in Cobol, ask them to use OO design principles in their coding, and then another group uses procedural. Remove all variables like language, database abstraction tools, etc.
@Peter,
One thing that this study I quoted did was look at 1st and 2nd generation applications. Now again, the study's metric may be questionable, but still they were able to find no productivity gains between the 1st and 2nd generation when comparing OO to procedural. Also, you have to consider that many people that make the switch from procedural to OO give up some VERY bad programming practices in the process. In other words, they could have stuck with procedural and made some serious improvements in their code reuse and other methodologies, without switching to OO. Before their OO switch, they were "cowboy coders", so of course they will see dramatic improvement when they switch to OO.
CF does so much for you, all you need to do is get in the seat and drive! If you need other stuff, people like Ike have built add-ons for you, but there's no need to worry about OOP or any of that stuff--leave that for the mechanics!
I don't use OOP in my work as a CF programmer and I am a happier person because of it.
It seems that there are really 3 separate areas to consider: depth of understanding of using OOP (patterns, best practices, experience), languages/language features that support OOP development (Java, C#, dynamic languages, APIs, libraries), and level of productivity provided by non-language capabilities that support OOP development (IDEs, frameworks, tools).
In all of these categories, the situation now is vastly different than it was in 1999. So I don't see how you can think these should remain static. The point isn't that at the time all of the developers were on even ground. The point is that OO developers now have huge advantages over OO developers from 1999. Productivity is about far more than just an understanding of OOP (though that is critical). It extends to how productive you can be in every other way as well. If I can use Hibernate to generate and execute an entire persistence layer in a day, when it would have taken a team of people a month to do the same thing, clearly I am vastly more productive. Don't you agree?
@Brock: There's nothing wrong with not using OO in your CF development. But if you don't know OO at all, you're going to have a very hard time being anything other than a CF developer in the future.
I do agree that using all those tools today would make you much more productive than in 1999. However, that is not OO, those are developer tools. But maybe we're talking semantics here. My point by saying those things need to stay static was that you were arguing that this study is too old, but if the question at hand is whether OO is more productive than procedural, and the OO principles are largely the same today than they were 9 years ago, the study from 9 years ago can still be valid today. However, if you want to find out if IDEs and code generators available today make you more productive (an entirely different question), than you should include those things in the study. However, the question that is asked in the study should NOT be "Is OO more productive than procedural?", but rather it would change to "Are modern OO programming tools more productive than OO programming tools available in 1999?"
But if you want to take things to that level, than I would argue that it is just as possible to achieve high productivity levels if one were to develop all the tools you mentioned to do procedural programming. If I had a one button tool that would generate an entire application for me using procedural code, it's hard to beat that no matter what methodology you use. But again, at that point we are not measuring programming methodologies anymore, but rather programmer tools.
Brian: Lines of code metric isn't very useful wrt measuring the productivity of OOP because there are so many other factors involved, with available tools, both IDE (Dreamweaver) and code (frameworks) playing a major role in prodoctivity. And in the last 10 years in particular there have been some major improvements in both flavors of OOP tools. We're not sure about procedural tools, but at least we're not aware of any major strides in that area. Hence a holistic picture of OOP productivity would have to concede that the "playing field" has changed a fair amount since 1999 (shortly after I started working with CF3 -- no OOP yet) and if we were going to cite any study to give us a real idea of the value of learning OOP it should be up-to-date enough to include these other influences on productivity.
Jake: On the other hand, if we're talking about taking a scientific approach to measuring the value of OO theory, we would need to address it as a serious line of scientific inquiry by doing what all good science does, which is break the phenomenon down to its smallest possible "atomic" parts for measurement. This is done by holding "all else equal" during the course of each experiment so that we can measure each element in isolation. So while you may (probably) want to measure the value of the tools (IDEs and frameworks), that needs to be done in a separate study. Once you have studies for each element you want to measure (IDEs, frameworks, core language theory), then you can combine the results from each study to produce a holistic picture of the advantages of a given collection of tools and techniques.
-- and just to put another twist in this, I would think you could view something like the site templating features in Dreamweaver (as a random example off the top of my head) as an advancement in IDEs for procedural development. So that gives you an opportunity to compare the productivity of procedural IDE tools to the productivity of OO IDE tools.
And I just want to reiterate a point that may have gotten lost in the debate. I do think that learing and using OO is a good idea. I stated my reasons in the last section of my post (before the conclusion). :)
In short, it means that a vast amount of mundane plumbing work is removed from one's plate, leaving them more free to concentrate on actually designing a maintainable application and on meeting client requirements. OO today lets people work at a much higher level of design since so much low level work is already done/simple to do.
This differential between now and 1999 is gigantic, and a huge amount of the work those people did by hand in 1999 are things that are part of the languages, or available via support tools. I don't think it makes much sense to talk about whether OOP is more productive without taking into consideration language features and the rest of the supporting items I mentioned.
If they mean OOP is no more productive than procedural code when all things are equal and everyone is coding in Notepad, that may well be true. But it is so far removed from the reality of development work that it is essentially meaningless. One other thing I think is missing from the study is the effect of OO on *future maintenance*, which is where it seems to deliver it's biggest benefits. I'd love to see a follow up study by the same people today.
Actually, they did look at this. All of the projects they studied had 2 "generations", or rather, after the first release, the developers came back and coded a second release. Again, they found no productivity gains for OOP in this 2nd generation.
MS isn't taking a step back with F#, they're looking forward. Functional languages like Scala, Erlang, OCaml, etc. are not procedural languages and can't be viewed as such.
That said, I still think that a large percentage of the overall programming community uses procedural programming, for better or worse (this includes all of the people that don't get involved in mailing lists/blogs/forums, they just program at work and go home to forget about computers). So this debate is very important for them, if nobody else. I think it's better for them to go into OO with a full understanding of what it means to take that step, rather than just following along like sheep.
Okay, I have to interject something here again... ;)
Actually that particular subset of programmers aren't likely to ever learn OO if they're not already using it. They're unlikely to learn much in the way of new techniques without being forced to learn it because of a corporate mandate. And honestly, OO isn't the kind of thing that a person learns well when forced to learn it. It would be like forcing someone to learn to paint. They're never going to become very good at it because they weren't interested in it in the first place.
There is actually a scientist who right now is studying the phenomenon of expertise (and forgive me I don't remember his name). Anyway he's done a bunch of different studies and turned up some interesting results. The average employee (i.e. most people) stops learning new skills in their career after about 5 years. This applies to everyone - mechanics, doctors, attorneys, etc.
There are exceptions, and likely all of the folks contributing to these comments fall in the exceptional category. The exceptions are the people who choose to push themselves, who, when given the choice between doing something they've already mastered and doing something they currently find challenging, choose to do the challenging thing.
Most people just aren't wired that way. Most people reach a comfort zone after about 5 years and then plateau. Those are the guys who forget about computers when they go home... and honestly, don't read blogs like this, which makes this debate useless to them, because they don't care. ;)
I do a lot of that stuff you mentioned too. I spend an hour or two most nights watching the news and Discovery Channel, and I have responsibilities with my Church, plus I do stuff with my wife and family that doesn't involve computers. But I still take the time to go to user group meetings on occasion, and participate in blogs, and develop open source software, etc. I am not saying that people should spend every hour of every day in front of a computer. But at least spend some time bettering your skills and participating in technical communities. When I said I have no respect for such people, I was referring to people that Ike was describing...they NEVER take the time to better themselves, even while they're at work. They believe they've learned all they need to know, and they stop progressing.
I think OO design is important. It is not always applicable, but when faced with a new problem, it's useful to break things down into objects and then describe what those objects do. You have to start from somewhere, and I think OOD is a good starting point.
OO programming I am dubious about. Someone mentioned all the tools available now for OO programming, but I counter that those tools are available because OO programming is so kludgy you need tools to debug it. You can't simply toss a few flags in your code and track down the issue - you have to have a development environment that ties together all the parts of program into something easier to handle.
Finally, I want to point out that the single greatest factor in programmer productivity is their own personal habits and organization, along with a solid design. Memorizing a bunch of tricks and syntax is nice, good tools are handy, but in my experience there are so many personal factors that impede people from finishing their jobs that choice of language dims in comparison. Add in a clear vs murky design, and I think "object oriented programming" hardly rates as a really important topic.
-Jeff
Interesting that you brought him up Ike. His name is Anders Ericsson. I studied under him when I was at FSU. He deals with expert performance though deliberate practice.
http://www.psy.fsu.edu/faculty/ericsson.dp.html
There is a lot to be learned from his body of work but I will boil it down to one axiom "Work hard AND smart".