Intuition and System Design

What is intuition? We often hear that "This is very intuitive." Intuition in simple terms is the ability to comprehend in a natural way. Intuition is also a function of one's background and experience. Intuitive for one may not be the same for others. For example, a painter knows how with a couple of strokes and adjustments of colours he or she can change the mood of the painting. But that capability has been built through years of practice. That is why I consider intuition as a relative term and not an absolute one. Intuitive for one may not be so intuitive for others. That also leads to another interesting thing that people interpret things based on their experience and background. Confirmation bias has a role to play here but it also is a function of the tendency to put lesser mental load while comprehending a thing. We are driven by our intuition and our intuition is a function of our experience and background. 

Serverless Architecture

The first thing to understand about Serverless architecture is that it's not about the absence of a server. What it means is that as a developer you are not concerned with the server. You provide a code piece to an environment and it will be executed and results will be returned to you. You are just responsible for providing the code piece and generally, the code piece has to adhere to some contract so that the execution environment can understand it. AWS Lambda is an example of Serverless architecture. 

Abstraction

Abstraction is the ability to build models. For example, you are dealing with a problem to be solved. The problem has its own details and nuances. To solve it, a human mind tries to build the model of both problems and then the solution. Both the problem and solution space can be made as specific or as generic. How specific or generic depends on the person doing the mapping. Depending on individual inclinations and capabilities, it might be very specific or very generic.

Abstraction has to be handled carefully in software development or for that matter in any problem-solving exercise of the world. The right level has to be achieved otherwise it will lead you to a rat hole, in the case of both under and over abstraction.

Let's look into the problems with under and over abstraction.

Perils of over abstractions

TOGAF

TOGAF is a framework for developing enterprise architecture. It's not a plain framework but contains a lot of supporting tools.  Main components of TOGAF are:

• ADM: ADM stands for Architecture development method. It's the core of TOGAF and contains step by step approach to build the enterprise architecture. With ADM comes a set of guidelines and techniques, which help in different steps of ADM.

ADM consists of following phases:

Interaction Data Model vs Transactional Data Model

In the days of Entity beans in 2.1 ways, the existence of beans required the need for a container or a run time environment to manage those beans. This made it impossible to transfer those beans across the wire or across contexts as it was not possible for the new environment to always understand those beans. This prompted the need for patterns like Value object and Data Transfer object. The idea was to map the beans into the same kind of structure and without the baggage of run time environment needs.VO/DTO essentially was about mapping the entity beans data structure into another similar beans structure.

Then the world changed and the entity beans got replaced with POJO's. It was first made popular by Hibernate and then adopted by Entity beans 3.0. This made VO/DTO sort of redundant as the entity

Object Oriented Approach to System Design

Before we delve deeper into technicalities of Object oriented or procedural, let's understand what "approach" on its own stands for. I am trying to delve deeper into the word "approach" because of one plain reason, that most of us fail to demarcate between the concept of means and ends. In any software development endeavor, the most important thing is and should be fulfilling of customer requirements. Rest all is fancy technicalities. I am using fancy, not to put the technologies in a derogatory sense, but to cautious developers from indulging into the self glorification aspect of technologies. As a developer we tend to feel proud of the number of frameworks we know or the intricacies of a server administration we understand. In this, many times the customer requirements are fitted on top of technologies.

Let's get back into our discussion on approach. What is an approach? An approach is a way to solve a problem. Approach represents the means and not the ends. The same problem possibly can be solved

How important are frameworks for Software Development

Not only in the Java world but in all the ecosystems of programming we have zillions of the framework which provide the notion that if that particular framework is used than applications will get done quickly. The marketing machinery works overtime to further these ideas. So is a framework answer to all the problems of the development. This is unfortunately very far from the truth. I am not saying that frameworks are not important. Let me say that, I do like frameworks and do use a lot of frameworks to do my job. In fact, given a problem statement, I do look around to figure out if some framework can do the job in a better way, rather me writing all the low-level stuff. A framework does bring a lot of advantages and important of them is to force the developers to follow industry-proven practices and patterns. Another important advantage I see with frameworks is that the popular frameworks carry with them a big community and strong knowledge base. At times there are example applications in the open domain to study. 

Software Development frameworks are panacea?

The human mind has a tendency to simplify everything, which is a good thing. But then there is a tendency to oversimplify by wrapping it up in such a manner that it just looks simple on the face. At present, there are many frameworks that have come up promising the paradigm of rapid application development. They are useful, in many sense that they do remove a lot of drudgery out of the development work. Especially drudgery related to a repeated task. The problem comes up when these frameworks promise the panacea for all the issues related to application development. Most of the benchmark against the number of minutes they take to build a shiny and neat CRUD applications. I would sincerely ask them to put a benchmark against how many minutes they survive after the initial honeymoon. How long they stand when the real-world problems start appearing. Many of them make

Reduce the concepts

The biggest problem for a developer today is not the lack of choices but the overwhelming number of choices. The choices exist at all levels right from the choice of platform to programing languages and than the choices of frameworks in the programming language. And it's not simple to make a choice. The primary reason of confusion is the fear of getting it wrong. For example, take web application. You want to do it in Microsoft, Java, Php, Python, Scala(Lift), Ruby on rails and other zillions way. If you happen to choose Java than  Spring, JSF etc for front end and similar choices existing for other layers. A tough nut to crack.

Lately I am coming to conclusion that for 95% (or may be 98%) of the cases, it does not matter which one is chosen. Everything will work equally good, give or take small differences. The difference lies