>>>>https://developers.slashdot.org/story/19/07/22/0426201/is-object-oriented-programming-a-trillion-dollar-disaster
>>>
>>>Interesting article. I guess you could write a similar article about procedural code. My take is to stay away from any puristic approach. Use the right tool for the right solution, and stay open minded. I do have seen NET and Java Code that goes beyond reasoning. On the other hand the mindless collection of public variables and scores of parameters have genereated many desaster projects. Done "right", any tool is a good tool if it fits the Purpose. But what is "Right" also may strongly depend on the context.
>>
>>I've seen disasters written in several languages, tools misused, and I can rarely assign the blame to the language or the programming paradigm. Most of the time I'd say it was either the programmer not knowing the language well enough, or not having a picture of how it should work/look when it's done, which again comes from lack of experience.
>>
>>That being said, there's also the collective learning curve. The first examples to imitate are rarely the best ones - they were written with nearly zero experience. Anyone remember the "framework" that came with VFP? Or the Codebook which called a container on the form a bizobject? And then consider the thousands of programmers who tried to follow that, not clearly distinguishing the language itself from the way it was used in those examples? It took us years to start writing clean code.
>>
>>I reserve a special remark for the mention of design patterns in the article. They weren't meant as more clutter to fill the programmers' heads with, on the contrary. They were common names for the things many people had to invent over and over and had to resort to long descriptions when communicating the works to others. So instead of saying "the heavy piece of metal on the end of a handle with which you hit things to drive them in or bend them", it's called a hammer. It actually reduces the clutter. Unless one feels a duty to implement them all, preferrably in the same app :)
>
>I agree whole heartedly with everything above. With design patterns, I wonder if not too often a design pattern, which was supposed to be an aid, became the goal of its own implementation.

I thought the most compelling part of the article was the drive for simplicity. That is, anything that makes development and maintenance more complex should be viewed with deep suspicion.

One project I worked on a while back was based on VMP and was worked on by 2 or 3 other developers before me. Finding where to drop in code to fix a bug or make an enhancement was the biggest part of the job. I felt exactly like this: https://www.buzzmaven.com/old-engineer-hammer-2/