Are software systems really abstract ?

Many a times when I promote the usage of engineering best practices in the software industry like the way it is used in other streams of engineering, The most common excuse given by the software engineers and their management is "Software systems are very different from other streams of engineering ... software systems are very abstract... software systems are very difficult as compared to conventional engineering systems etc." And hence they staunchly defend their stand while trying to avoid the usage of engineering best practices.

I feel these excuses are incorrect and are mostly due to lack of proper knowledge about software systems.

As I have been doing repeatedly , let me again take you back to our version of "Software Systems".

Most of the people fail to understand that software system is nothing but an automation system like any other automation system belonging to any other stream of engineering and follows the same set of steps during its design and development.

Please read topics like "" and "".

Ask your self what is the difference between Human beings and Computer Systems?

Ask your self why are Software Systems primarily modeled from Behaviorial and Structural Perspective?

Ask your self why are UML Diagrams classified as "Structural Diagrams" and "Behaviorial Diagrams"? Why not something else?

Ask your self why are Core Design Patterns classified as "Structural Design Patterns", Behaviorial Design Patterns and Creational Design Patterns? Why not something else?

In the topic "" I have shown you the similarity between "Software systems and Real World" and have shown you that the only difference between the software system and the real world is "In the case of real world we deal with physical locations while in software systems which are object oriented .. we deal with memory locations ... this is the most significant difference . Most of the other things are the same."

Ask yourself why are all the object oriented programming languages designed to ensure that they are capable of representing the real world in its most natural form and for concept that they are not able to represent naturally, they have provided work around to handle those concepts.

Ask yourself why are your programming languages, frameworks, tools, IDEs are designed using core design patterns ?. As I have shown you in this topic "" Core design patterns are design best practices that are borrowed from real world and the conventional streams of engineering.

Ask yourself why are most of your software systems designed using the arrangement of Domain Entities, Control Entities and Boundary Entities like the way the systems belonging to other streams of engineering are designed to work? In my topic "" I have shown as to why the arrangement of domain , control and boundary entities have become a fundamental design style within systems.

As I have demonstrated the same in my other topics as well, software systems and its best practices are borrowed from the real world and systems belonging to other streams of engineering.

There are numerous programming languages, frameworks, software systems, IDEs, tools, Design Patterns that will justify my reasoning's.

If you read all my articles on requirements gathering, analysis and design, you will realize that software systems are just like any other system in this world having both structure and behavior as there cannot exist a system in this world without structure.

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer