The idea of object-oriented software originated in the 1960s and rose to dominance in the 1990s. In 2019, most main-stream languages are at least somewhat object-oriented. Despite this obvious success, the paradigm is still somewhat nebulous if you think about it in detail. What does it really mean to write object-oriented code? A multi-paradigm language like Java claims to be object-oriented, but a lot of Java code out in the wild looks quite procedural. Is there any meaningful difference between a Java bean and a simple data structure like a C struct (except that the Java bean requires more lines of code)? What needs to be done to finally make software engineering reach the next level, where we can write bug-free, maintainable code on time and on budget? There was a lot of hype around object-orientation (OO) in the 90s and clearly the paradigm hasn’t lived up to the hype: Today’s code is still mostly not reusable and strong modularization isn’t widespread either. And here is where the quest for true OO comes in.

Some software experts believe that the promised benefits of object-oriented software can be achieved if the code is structured correctly. One prominent believer in true OO is Dave West. In his book Object Thinking he lays out the correct mindset needed to build truly object-oriented software. The book is highly philosophical and while interesting not really usable in practice. In fact, he mentions later in the book that no currently available programming language is truly object-oriented from his point of view. While he mentions having used true OO in his work as a software consultant, he never shares any real-life code. This is quite disappointing as it would greatly clarify his ideas. One core idea in the more concrete parts of the book is that of self-evaluating business rules. Each rule is supposed to represent a process in the business domain (e.g., calculating somebody’s salary) and should have the ability to evaluate, i. e. execute, itself. In West’s approach the business rules are the core of the software with only small layers for presentation and data storage around them. While this seems like a sound idea, West sadly never gives a code example for such a business rule. All in all, he stays frustratingly vague in his book.

Another true believer in the idea of OO is Yegor Bugayenko. Yegor is known for his unorthodox programming style and was influenced by Dave West. Like West, he believes that object-oriented programming requires a different mindset and that current languages are not up to the task. I’ve written a review of Yegor’s book on this very blog. You can take a look in there for a more detailed glimpse into Yegor’s mind. While I consider his contributions interesting and somewhat stimulating, he suffers from the same problem West has: Too much philosophical fluff and too few concrete examples to back up his claim.

I don’t want to pick on West and Yegor, they are just the two most prominent examples of somewhat current OO believers I know. In general, I think they are on a fool’s quest. I think Fred Brooks was right and there is indeed no silver bullet for the problems plaguing software engineering. No programming paradigm will suddenly solve our eternal problems (lack of time, lack of quality, lack of budget, lack of maintainability). At the very heart of these problems are humans not technology. We end of up with impossible deadlines, because we are terrible at estimating software development and/or we are under pressure to make the politically acceptable estimate. We end up with low quality software because developers have too little time, are untrained or just don’t care about quality. Everything ends up costing more than originally planned, because the initial estimation was completely unrealistic from the get go. It was made under the assumption that the customer wouldn’t agree to the deal if he knew the real number. Also, the budget gets overdrawn, because the requirement engineering is lackluster and as a result everything takes longer than expected. And last, we’ve got poor maintainability because of bad code structure, too few automated tests and sloppy design which are all caused again by a lack of time, interest and quality. All these problems can be avoided by careful planning, defensive estimation, a quality mindset and honest communication. No different programming paradigm needed.

But let’s for the sake of the argument assume that deeply buried under the layers of confusion and misleading information lies a golden heart: A way to reap all the benefits OO supposedly has. How come so few people have seen it over the last fifty years? How usable is a programming paradigm if its benefits are only attainable by a handful of people? Is it worth the effort to train the rest of the programming community or are they beyond hope? What is the timeline until a break-even point is reached? Dave West states on page 30 of his book that a lobotomy is required to turn a procedural programmer into an object-oriented programmer. How many programmers can (and are willing to) unlearn everything they think they know about programming especially if they have supposedly done OO for years? You can probably see the point of all these rhetorical questions already: I think that reality has already proven that there is no “true” OO which will deliver us into software heaven. That doesn’t mean that I hate the paradigm: In fact, I’m young enough that OO was the first programming paradigm I was taught and it still is the paradigm I’m most familiar with. However, my style is very reduced and has nothing in common with the overly complicated patterns and practices of the nineties (think of the famous gang of four book for example).

All in all, I’m convinced that the discussions about paradigms, languages and tools which are so virulent in the software development community are a waste of time. When simply writing software as a hobby, any developer is free to pick whatever he wants to. In a commercial environment, software exists to solve a problem. What tools, languages and paradigms are used in its creation are of zero relevance to the customer. While there are situations in which certain tools, languages or patterns might be more suitable than others, it is by no means a business-critical decision. There are successful software projects around in any paradigm. Facebook wrote most of their codebase in PHP, Discord uses Elixir and SAP became a market leader using a (originally) procedural language like ABAP. It is much more productive to focus on value creation for the customer and high-quality work than to hunt for some magic way to write software which solves all problems. I understand that new/hyped topics and technologies are attractive to developers, but what good is your cutting-edge work if no one uses it in the end? Useful software isn’t always exciting, but it both pays the rent and makes the world go round. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.