OO is getting old and tired. But is it dead yet?

Here are a few thoughts inspired by an excellent presentation with a provocative title “Object-Orientation is Dead, too” by Dave Thomas aka @pragdave.

OO has been taken to mean classes, inheritance and polymorphism, as implemented in a variety of programming languages. As we typically build code, the proper class design is to commingle state and behavior. Inheritance provides a simple way to vary some but not all aspects of behavior on connected objects. And polymorphism provides a way to package different behaviors into look-alike syntax.

Together, these features make for an incredibly flexible system, with many different ways to design abstractions, express dependencies, and store state in many objects across the codebase. Other words for flexible are ‘complex’ and ‘complicated’. The notion that having all this flexibility is good and powerful and smart encourages mixing a variety of abstractions and implementations, and long and wide dependency trees. As systems and corresponding codebases grow over time, accumulating ideas and approaches from many people, they grow more fragile, more tightly-wound. Code also becomes more dependent on the past history, rather than the latest, and therefore best, understanding.   

We know all that because OO had had a great run in the last 25+ years. Java, in particular, has been one of the most popular programming languages since it came out in mid-90s, both by the amount of code written and number of people writing in it. .Net platform is heavily OO and is very popular as well. C++, while not exactly a strictly OO programming tool, is frequently used for OO-style development. Lots of complicated projects have been attempted, and plenty completed, using the OO paradigm. Many people joined the ranks of OO developers, people with varying amounts of education, imagination and cleverness.

In the last quarter century OO paradigm has been applied to many complicated development projects, at times by less-than-stellar developers, and often by diverse groups working independently and inconsistently. OOP came out somewhat scathed, bruised by the many broken abstractions, blemished by millions of lines of legacy code, but by and large OO has delivered on its promise to provide a way to make large and complex systems possible.

So, is OO dead yet? Or, rather, are we ready to move on to something newer and better?

It’s been many decades since OO first showed up, handily won over then-popular procedural programming style, and far eclipsed the popularity of the functional approach. We are now older, wiser, and have more experience. Is OO still the silver bullet it has once been? And what are our options?

Functional languages are powerful, deeply loved by their communities, and offer a paradigm that can rival OO tools in solving complex problems. Yet, the functional approach has not enjoyed nearly as wide an adoption among broader development community. It also did not have such a testing 25+ years, as software projects grew larger, more complex, and continuously involved larger numbers of less skilled people than ever before.

The functional paradigm is worth exploring again, with the experience we did not have back when OOP originally came along and took over the software industry. But the winning paradigm for the next quarter century is far from certain.  

Solving for Passion

For the last few years, I have had the pleasure, and the privilege, to participate in graduating students’ project reviews at a major university.  Students in their final semesters of earning a Computer Science or Computer Engineering degree are asked to come up with and implement a project of their own choosing, within the guidelines set forth by the professor for the course. Students typically identify a user or a client for their work – a university department or research lab, consumers, charitable organizations.

A few dozen projects I have reviewed so far have mostly been spectacular. Students put their heart and soul, and considerable skills and passion for the technology, into this assignment.  However, there are interesting differences in the presented work.

Some cohorts of students appear to have lofty, large-scale goals. They are interested in solving big important problems related to hunger, or low productivity, or deadly deceases for large populations using tiniest of tools. The teams pull research from international conferences and large NGOs, make highly speculative assumptions about complicated unknowns, and pull together technologies that are both rare and not really designed for these purposes.

For these projects, results are typically modest, presentations are ambitious on vision and poor on structure, and risk of running into crippling unknowns is high.

Other groups appear to be much better prepared. The projects capitalize on the cutting-edge technologies, tests are neatly recorded on video, and presentation slides showcase the scientific background and beautiful technical documentation.  However, these projects aim a bit lower: gadgets that offer a small improvement on the existing products.  Polish replaces passion.

When the focus is on delivering a good-looking presentation, creativity gets lost, or at least greatly diminished. This batch of working, well-documented projects lacks excitement, grand vision, reach into the unknown.

College is the time to dream, to stretch for the moon, to grow one’s ambitions. Most people go on to have a long and very practical career, where delivering a small improvement is valued higher than big ambitious undertakings. We will all be better off if we had more passion and creativity to go around. 

Beyond the 'happy path'

In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected

- Wikipedia

Software is possible because we have clear, well-defined expectations in a lot of common situations. Given a problem and a particular state of the world, software can reason through known information, and perform according to the expectations.

People who invent software are enterprising, excitable, focused on delivering a working solution for a problem.  Which mostly translates into building software that is great about performing the ‘can do’ portion of the expectations. It is the so-called happy path, where the software works as desired and designed, in the perfect world for the well-behaved user who happens to think in perfect lock-step with the inventor of the software.

However, the world is hardly ever perfect. People and users think differently. Not all users are both well-behaved, and can or will follow the detailed vision of the software designer.

Consider a bank application that allows read access to one’s account balance. It is important that it does NOT

• allow read access to other people’s account balance.
• allow write access to any account balance.
• allow any user behavior to affect other user’s experience and access.

These kinds of expectations are less likely to be included in the specification, because we like to think about software in terms of what it can do, and not what it doesn’t do. These expectations are less likely to be designed into the software architecture, because we like to think of achieving our goals must more, than we like to be concerned about preventing bad things from happening. Finally, these expectations are less likely to be tested, because it is both harder and does not demonstrate a job-well-done even if successful. 

Better handling the non-happy paths requires a more systematic approach to specification building and testing, and range verification.