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

  1. Abstraction is provisional.
  2. Properties of a component are properties of interaction between components
  3. Introduction to inverse problem in abstraction
  4. To think is to forget: Abstraction is only partially visible
  5. How to live with imperfect abstraction

Learning Outcome

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:

  1. 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.
  2. 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.
  3. 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.

Target Audience

Developers, Architects, Business Analysists

schedule Submitted 3 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Leena S N
    By Leena S N  ~  2 months ago
    reply Reply

    Hi Shripad,

    Can you provide outline of the slides for the presentation and an intro video too? A video of you presenting at some other conferences will suffice too. This will help the organising team to understand your presentation skills better.

    Thanks,

    Leena

  • Anand Bagmar
    By Anand Bagmar  ~  2 months ago
    reply Reply

    Hi Shripad,

    This is an interesting submission. What kind of examples will you be sharing? Will there be a demo?

    • Shripad Agashe
      By Shripad Agashe  ~  2 months ago
      reply Reply

      Hello,

      As mentioned in the abstract, I will be concentrating on discussing the topic in context of a lock and a key. A lock is a lock because of the key and vice versa. So if we take those notions or ideas away we will grapple with modeling the system.

      I am going to exhibit modeling of unknown context via Paul Jakcon's single fold origami. (https://passionforpaperandprint.wordpress.com/2014/04/21/paul-jacksons-one-crease-folds/). He makes a point that origami model's of known types like a boat or an elephant are easy to asses and relate to. However if an absrtact form which does not relate to anything in real life, it becomes immensely difficult to asses whether it is right or wrong or goood or bad. 

      Another example is this sentence from ClockWork Orange I will be analyzing during the talk is: "“Our pockets were full of deng, so there was no real need from the point of view of crasting any more pretty polly to tolchock some old veck in an alley"

      As absrtactions are a more general concept that programming, i will be mostly covering it via scenario analysis rather than actual code examples or demos.