The myth of perfect abstractions
Deriving abstractions for a given problem description is always challenging. No matter what your experience level is, a new scenario will always be challenging to model. At the core of the problem is something known as "Inverse Problem" i.e. it is often easy to observe abstractions in hindsight than in foresight.
The modeling that we do,deals with IT systems and people operating those systems. What transpires from it is that the observed behaviour of a system is always a reflection of interference of multiple responsibilities of that system. To give an example, a lock is a lock because of the key. Should we lose the key, the lock is just another dead weight. So when we verbalize lock, certain properties come to our mind and weight is not one of them. But the properties that we perceive as properties of a lock are indeed interactions between a lock and a key.
It is very easy to extrapolate the lock example for unknown scenarios. In such cases we struggle because we have no clear idea about the underlying components and their interactions. So our best attempts are guess work. And if it works for scenarios at hand, we should stop generalizing. By extension of this argument, we can see that we should not strive for universal abstraction but try and model based on certain heuristics and create a workable domain and leave our abstractions incomplete. At the same time, we should have the humility to accept that our abstractions may be wrong but we should be ready to change them if such a need arises.
To conclude, in the session, I want to highlight difficulties faced in creating abstractions and how to cope with such difficulties. This is useful from developers to system architects and even CTOs to some extent.
Outline/Structure of the Talk
- Abstraction is provisional.
- Properties of a component are properties of interaction between components
- Introduction to inverse problem in abstraction
- To think is to forget: Abstraction is only partially visible
- How to live with imperfect abstraction
The attendees will take away a different way of looking at the process of modeling in software. This technique is useful right from basic classes to modules to large scale system design.
The key takeaways from this session are:
- Abstraction is emergent. As new requirements come in, the requirements highlights the abstraction within a system. So dependent on arrival of requirements the system may evolve with different abstractions.
- The provisional nature of abstraction is about validity of a particular concept. As we learn more about the systems, abstraction will need to change. Developers and architect should be ready to change the abstraction rather than force-fitting new requirements on existing concepts.
- Rather than worry about future requirements impacting abstractions and design, one should focus on following right development practices like SOLID principles, unit testing and refactoring. The focus should be to create just about right abstraction for the current requirement set and ability to quickly change the abstractions as the system evolves. Here development practices come to aid the process of quick changes in abstraction.
Developers, Architects, Business Analysists