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 prog

Answer 1

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 2

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.

Answer 3

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 4

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.

1. Time to build something that works.

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

Answer 5

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