Development Cost of Procedural Programming vs. OOP?

After poking around with google I found this paper here The search terms I used are Productivity object oriented The opening paragraphs goes on to say Introduction of object-oriented technology does not appear to hinder overall productivity on new large commercial projects, but it neither seems to improve it in the first two product generations. In practice, the governing influence may be the business workflow and not the methodology I think you will find that Object Oriented Programming is better in specific circumstances but neutral for everything else. What sold my bosses on converting my company's CAD/CAM application to a object oriented framework is that I precisely showed the exact areas in which it will help.

The focus wasn't on the methodology as a whole but how it will help us sold some specific problem we had. For us was having a extensible framework for adding more shapes, reports, and machine controllers, and using collections to remove the memory limitation of the older design.

After poking around with google I found this paper here. The search terms I used are Productivity object oriented. The opening paragraphs goes on to say Introduction of object-oriented technology does not appear to hinder overall productivity on new large commercial projects, but it neither seems to improve it in the first two product generations.In practice, the governing influence may be the business workflow and not the methodology.

I think you will find that Object Oriented Programming is better in specific circumstances but neutral for everything else. What sold my bosses on converting my company's CAD/CAM application to a object oriented framework is that I precisely showed the exact areas in which it will help. The focus wasn't on the methodology as a whole but how it will help us sold some specific problem we had.

For us was having a extensible framework for adding more shapes, reports, and machine controllers, and using collections to remove the memory limitation of the older design.

– ceretullis Feb 13 '09 at 2:42 Poking around the site I found a PDF with this note Published in Software – Practice and Experience, Vol. 29, No.10, pp 833-847, 1999. – RS Conley Feb 13 '09 at 14:01.

Most all of these questions are confounded by the problem that individual programmer productivity varies by an order of magnitude or more; if you happen to have an OO programmer who is one of the gruop at productivity x, and a "procedural" programmer who is a 10x programmer, the procedural programmer is liable to win even if OO is faster in some sense. There's also the problem that coding productivity is usually only 10-20 percent of the total effort in a realistic project, so higher productivity doesn't have much impact; even that hypothetical 10x programmer, or an infinitely fast programmer, can't cut the overall effort by more that 10-20 percent. You might have a look at Fred Brooks' paper "No Silver Bullet".

OO or procedural offer to different way to develop and both can be costly if badly managed. If we suppose that the works are done by the best person in both case, I think the result might be equal in term of cost. I believe the cost difference will be on how you will be the maintenance phase where you will need to add features and modify current features.

Procedural project are harder to have automatic testing, are less subject to be able to expand without affecting other part and is more harder to understand the concept part by part (because cohesive part aren't grouped together necessary). So, I think, the OO cost will be lower in the long run compared to Procedural.

I can tell you that almost 100% of the work we have to do in our shop is maintenance... so yeah it would seem like OO would be the way to go. – ceretullis Dec 8 '08 at 14:55.

I think S. Lott was referring to the "unrepeatable experiment" phenomenon, i.e. You cannot write application X procedurally then rewind time and write it OO to see what the difference is.

You could write the same app twice two different ways, but you would learn something about the app doing it the first way that would help you in the second way, and you may be better at OO than at procedural, or vice-versa, depending on your experience and the nature of the application and the tools chosen so there really is no direct basis for comparison empirical studies are likewise useless, for similar reasons - different applications, different teams, etc. Paradigm shifts are difficult, and a small percentage of programmers may never make the transition if you are free to develop your way, then the solution is simple: develop things your way, and when your co-workers notice that you are coding circles around them and your code doesn't break nearly as often etc. And they ask you how you do it, then teach them OOP (along with TDD and any other good practices you may use) if not, well, it might be time to polish the resume... ;-).

Two comments. (1) I think it a stretch to say S. Lott was referring to this phenomenon, BTW thnx for noting the phenomenon here.

I'd forgotten about this... but I was really wondering if anyone had done a non-scientific study. Surely some software shops have made the conversion and noted the cost? – ceretullis Dec 2 '08 at 3:10 (2) this is my first "professional" programming job, I have a Master's in CS and have been programming since childhood... after months of looking this was the only software development offer I got.

– ceretullis Dec 2 '08 at 3:20 @ceretullis: keep looking, in the meantime, try to blend in ;-) – Steven A. Lowe Dec 2 '08 at 3:41 @ceretullis: Indeed, I am referring to the fact that software experiments are always suspect because they can't have repeatable controls. Software development is knowledge capture; it's the worst kind of unrepeatable uncontrollable phenomenon.

– S. Lott Dec 2 '08 at 12:18 @S. Lott: I would say the 'worst kind', I think the worst kind is the 'fantasy' kind, like "my team would have won if I had been there to cheer them on" ;-) – Steven A.

Lowe Dec 2 '08 at 14:25.

Good idea. A head-to-head comparison. Write application X in a procedural style, and in an OO style and measure something.

Cost to develop. Return on Investment. What does it mean to write the same application in two styles?

It would be a different application, wouldn't it? The procedural people would balk that the OO folks were cheating when they used inheritance or messaging or encapsulation. There can't be such a comparison.

There's no basis for comparing two "versions" of an application. It's like asking if apples or oranges are more cost-effective at being fruit. Having said that, you have to focus on things other folks can actually see.

Time to build something that works. Rate of bugs and problems. If your approach is better, you'll be successful, and people will want to know why.

When you explain that OO leads to your success... well... you've won the argument.

Thnx 4 the comments. I'm not sure this is comparing apples to oranges. It is like saying I can't compare two different ski-jumping techniques... which clearly can be done... though this has the same issue as it depends on the relative skill of the practitioners in their respective styles.

– ceretullis Dec 2 '08 at 2:20 Disagree: not like ski-jumping. There's little objective difference, unless you fall. Much of the scoring is judging "style".

And everyone lands within meters of each other. I'm saying it's like comparing ski-jumping and SCUBA diving. Too few similarities.

– S. Lott Dec 2 '08 at 2:42 But why not compare KLOCs (to start with) or (recorded) keystrokes (both utilized to "type-in" and modify code during development)? It seems that could be easily done within basically the same "environment" (for example for C and C++) and possibly give interesting and helpful results, which could be tied at least to the notorios "expressiveness" of OO and procedural languages / styles.

– mlvljr Jun 13 '10 at 9:43 @mlvljr: Keystrokes? Including backspace? Seems silly.

Lines of code is -- a priori -- unfair because the OO folks can use inheritance. If you want to play "code golf" all you'll learn is that minimizing lines of code makes software obscure no matter what style of design you use. – S.

Lott Jun 13 '10 at 19:28 Well, the amount of typing needed to implement a task (incl. Re-typing, and thus counting backspace hits:) ) looks to me like a good means of capturing the ease (and need! ) of introducing change to the already implemented pieces of the software being built while developing it (such changes will probably include reimplementing some "components" due to contract changes, refactoring them or even throwing some away).I.e.

If there is less typing for the same task, then one methodology suggests a more effective "coding strategy" (in some sence) than the other, and this knowledge is possibly useful. – mlvljr Jun 17 '10 at 20:08.

The key is time. How long does it take the company to change the design to add new features or fix existing ones. Any study you make should focus on that area.My company had a event driven procedure oriented design for a CAM software in the mid 90's created using VB3.

It was taking a long time to adapt the software to new machines. A long time to test the effects of bug fixes and new features. With VB6 came along I was able to graph out the current design and a new design that fixed the testing and adaptation problem.

The non-technical boss grasped what I was trying doing right away. The key is to explain WHY OOP will benefit the project. Use things like Refactoring by Fowler and Design Patterns to show how a new design will lower the time to do things.

Also include how you get from Point A to Point B. Refactoring will help with showing how you can have working intermediate stages that can be shipped.

I don't think you'll find a study like that. At least you should define what you mean by "cost". Because OOP designing is somehow slower, so on the short term development is maybe faster with procedural programming.

On very short term maybe spaghetti coding is even more faster. But when project begins growing things are opposite, because OOP designing is best featured to manage code complexity. So in a small project maybe procedural design MAY be cheaper, because it's faster and you don't have drawbacks.

But in a big project you'll get stick very quickly using only a simple paradigm like procedural programming.

Cost over time would be an appropriate metric. I mean the literal definition of cost, what you have to pay in overhead to get things done. – ceretullis Feb 12 '09 at 0:40.

I doubt you will find a definitive study. As several people have mentioned this is not a reproducible experiment. You will find anecdotal evidence, a lot of it.

Some people may find some statistical studies, but I would examine them carefully. I am not aware of any really good ones. I also will make another point, there is no such thing as purely object oriented or purely procedural in the real world.

Many if not most object methods are written with procedural code. At the same time many procedural programs use OO methodologies such as encapsulation (also call abstraction by some). Don't get me wrong, OO and procedural programs look and are different, but it is a matter of dark gray vs light gray instead of black and white.

I agree with your comment about not being pure OO. By the strictest definition C++ is not an OO language. There is a certain mentality in OOD where that encourages encapsulation and abstraction in more meaningful ways than you typically see in procedural code.

– ceretullis Feb 12 '09 at 0:42.

This article says nothing about OOP vs Procedural. But I'd think that you could use similar metrics from your company for a discussion. I find it interesting as my company is starting to explore the ROWE initiative.In our first session, it was apparent that we don't currently capture enough metrics on outcomes.

So you need to focus on 1) Is the maintenance of current processes impeding future development? 2) How are different methods going to affect #1?

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.