Comment Re:OOP is fine (Score 2) 386
OOP was sold to management on the basis of making maintenance more ... "manageable:" its re-usability features would make it easier for software engineers/technicians/slaves (now you know my bias) to be transferred between projects because coming up to speed on a new project would be that much easier. I know; I was there when OOP was first being pitched at IBM: people disparaged it as "just the latest attempt (after GOTO-less coding) to turn dog catchers (the unskilled) into programmers." Concurrently OO Design was pitched to the aerospace and financial industries (along with Ada) as a means to reduce the design-level fault rate.
All of this was dictated by the desire to evolve engineers from an ardently determined but unruly gang to a still ardently focused but easily interchangeable assemblage. That "easily interchangeable" point is key: it costs a lot of money to care for and feed engineers and the art of their deployment is foremost in the minds of middle and lower-level management.
History's verdict is, "Yeah, THAT worked well ... didn't it?"
-Rant-
The goals that OOD/OOP were to accomplish were eventually satisfied by converting software engineers from professionals to gig-economy itinerant technical comestibles who are driven by only delivery and cannot have a long-term investment in a product's sufficiency. Who cares if the engineer is under utilized? Furlough him/her and re-engage later! Who cares if the output is maintainable? It's going to be disposed of and recreated in short order anyway!
OOP was never actually used. Don't believe me? Look at the preponderance of function identities that lead an object with a verb (even in strict environments): createAThing, disposeOfAThing ... fesselAnAardvark, shaveAYak. OOP, if properly used would dispense with the object's identification: AThing.create, AThing.dispose ... AnAardvark.fessel, AYak.shave. Even when a language, such as Java or C#, impels the coder to form OOP-conformal names, the design documents are invariably non-OOD (dare I say ANTI OOD): they are full of Fesselings of Aardvarks and Shavings of Yaks.
-End of Rant ...er... Rant.End-
All of this was dictated by the desire to evolve engineers from an ardently determined but unruly gang to a still ardently focused but easily interchangeable assemblage. That "easily interchangeable" point is key: it costs a lot of money to care for and feed engineers and the art of their deployment is foremost in the minds of middle and lower-level management.
History's verdict is, "Yeah, THAT worked well
-Rant-
The goals that OOD/OOP were to accomplish were eventually satisfied by converting software engineers from professionals to gig-economy itinerant technical comestibles who are driven by only delivery and cannot have a long-term investment in a product's sufficiency. Who cares if the engineer is under utilized? Furlough him/her and re-engage later! Who cares if the output is maintainable? It's going to be disposed of and recreated in short order anyway!
OOP was never actually used. Don't believe me? Look at the preponderance of function identities that lead an object with a verb (even in strict environments): createAThing, disposeOfAThing
-End of Rant