Object-oriented programming (OOP) is built on abstraction, encapsulating both data and behavior into “objects.” While this approach has dominated software development for years, it doesn’t always align with how programs are created and executed. Often, the abstractions OOP introduces feel mismatched with the dynamic nature of software design and operation.

A key problem lies in how OOP connects data and operations. Take the example of a “person” object in a system. Attempting to define everything a person can do or be involved in within a single object quickly becomes impractical. People interact with systems in countless ways, such as being members of different groups, triggering workflows, or being part of external processes. Trying to encapsulate all these interactions within one abstraction leads to unnecessary complexity and rigidity. Software is not inherently about “things” or “objects”—it’s about tasks, processes, and services.

Much of software development is process-oriented. Applications often center around actions that need to be performed, such as validating business logic, fetching data, or completing a workflow. Similarly, functional programming approaches emphasize operations acting on data rather than tightly coupling both into objects. These paradigms reflect an underlying truth: software is primarily about what happens, not static representations of entities.

Thinking about software as “something that happens” can lead to cleaner, more practical designs. Programs are dynamic systems where tasks unfold over time based on input, rules, and workflows. By focusing on what needs to be done rather than forcing abstractions into objects, developers can design systems that align more closely with how software actually operates.

This doesn’t mean abandoning object-oriented programming entirely. OOP can be useful when modeling concepts with clear boundaries and well-defined behaviors, but it’s important to recognize that abstractions based on static objects are not always the best fit. Often, process-oriented thinking offers a simpler and more scalable solution, especially when software revolves around actions rather than entities.

Developers don’t need to follow a rigid paradigm, but rethinking abstractions can lead to better decisions. Software is dynamic, and understanding it as tasks, processes, and workflows rather than a collection of objects can help developers create more practical and adaptable solutions.