Does Object Oriented Programming Boost Productivity?

When done right, object oriented programming (OOP) converts the imperative nature of procedural programming into a set of declarative entities with imperative calls within and between them. The advantages of better reasonability, reusability and all the others depend on this. However, I am yet to meet someone who is able to take full advantage of these properties at the outset. Most neophytes treat classes and the resulting objects as ad hoc containers of some state and fail to assess the underlying application's needs for persistent classes to capture. I had a colleague who wrote an 8k LOC class with every method acting on a set of instance attributes. Therefore, the benefits are enjoyed to the extent that one rigorously carries out a design that discovers the underlying classes. In other words, the barrier to the fulfillment of OOP's benefits are solely tied to one's ability to adequately elicit a design that accurately represents the domain. In the case of my colleague, he had not taken the time to discover the set of classes that would be acted upon by the methods resulting in a linear expansion of the class with every new feature.

And yet designing for OOP is extremely simple. Given that the goal of OOP is to represent the relevant entities as classes, then a quick traversal through the problem space should reveal these classes. This doesn't happen or rather happens to much less an extent than most tend to do so. From my experience, two reasons are responsible:

1. Syntactical overload. The actual code used to define classes tends to be technically detailed and often involving vague ideas such as virtual, class and static methods, operator overloading, and many others which take more than a few exposures to grasp and then master.
2. Not going far enough. The process of writing classes usually involves writing a lot more code that a complete representation of all the entities would result in an order of magnitude more code than one would write procedurally. Despite its propensity towards verbosity, this is good. Having the fuller explicit representation in code rather than being implied to be consumed by functions is much better practice since anyone interacting with the code will not have to try and infer what types are being acted upon by functions.

While the benefits are there, it takes many more years of programming to enjoy them. Effectively, this means that most people will not confer these benefits on users of their code until they have overcome the technical hurdles of both writing the required code and mastering the underlying concepts to make use of them.

Does OOP boost productivity? Not in the short run but if you keep at it...