Development Cost of Procedural Programming vs. OOP

Question

I come from a fairly strong OO background, the benefits of OOD & OOP are second nature to me, but recently I've found myself in a development shop tied to a procedural programming habits. The implementation language has some OOP features, they are not used in optimal ways.

Update: everyone seems to have an opinion about this topic, as do I, but the question was:

Have there been any good comparative studies contrasting the cost of software development using procedural programming languages versus Object Oriented languages?

Some commenters have pointed out the dubious nature of trying to compare apples to oranges, and I agree that it would be very difficult to accurately measure, however not entirely impossible perhaps.

Answer 1

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

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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... ;-)

Answer 6

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.