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

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".

Answer 2

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.