To build is to visualize and create. In any core science, a necessity triggers a process which culminates with an solution for the problem which mandated the search for an answer in the first place. Since ancient times a need has driven the human kind to reach out of the sphere of its intelligence and come up with an “Idea” which is thought not possible in the prevalent realm of finite.
There have been innumerable ideas which have given a new course to the direction in which the world has moved. A wheel may be the mother of all inventions also laying claim to the earliest possible inventions known to humankind. A wheel was driven by the need for momentum and it has passed through various stages from a oblong rock in the earliest period to the composite spheres which we are now building for robots which can use them to travel on any surface.
This whole process of the solution for momentum can be segregated into 3 parts, the need which is the requirement for momentum between two finite points, an idea which foresaw motion and the engineering aspect which converted that idea to concrete elements like a wheel.
The engineering has gone through many iterations in from the ages when humans may have traveled a bumpy ride between the caves on a night out of home made beer to the work of art wheels we see today on some of the vehicles made of carbon composites and having the capacity to bear speeds which routinely break the sound barrier. What has stayed consistent though is the need which is momentum and an idea which fulfills that need.
Software as different it appears to be to the layman also follows the principle of a core science namely software architecting and software engineering. Given the need for a solution a software can be architected and then engineered. It is similar to a dam being visualized, architected and then built or for that matter an automobile being visualized, designed and built. Software also supports visualizing, architecting and then engineering. If only we get down to identifying and following the process in the true sense.
A building wrongly built is visible, a dam wrongly architected is a fatal danger, a automobile designed in an ugly fashion is open to ridicule but a software which is wrong architected or engineered stays out of the sight by the inherent quality of software which gets it treated differently.
An application shutting down on a daily basis draws at most our curses while if our car did that ahem, would not like to be in the shoes of the person who sold the defunct vehicle in the first place.
Software as we know today is patch built and not architected, we have so many frameworks floating around but not a single one stresses on the need to visualize and then engineer. We have so many unknowns in the design of an software when we start the actual construction that we end up building a system and then patching it up to make it work the way we wanted it to be built like.
Visualization is a science where we can think of out of the box solutions, ideas which can range from the unorthodox to the mundane. Architecting is like a science which runs like a dream, which is not bound by the dimensions and constraints known to us. How many times have we had brainstorming sessions in our teams when faced with a requirement which would either take too long to create and too costly to implement. How many times have we shouted down someone who had the gumption to stick the neck out and propose something radical or something too simple to be considered a solution. Some of the answers out there for questions which are hard to understand are simple in nature. We do not need the unnecessary mumbo jumbo and expressions running into a vocabulary of a 3 times doctorate holder to always solve something complicated. We pour resources in time, money and efforts solving bottlenecks without out seeing if there is an alternative to the idea itself. Imagine if human mind did not have the inherent quality to find alternatives we would still be driving vehicles on oblong tyres - ouch…
A messy rendering of a 3-Dimensional object which can only be rendered but not constructed.
Imagine trying to build everything we could possible think of, imagine trying to build the image above in the constraint of 3 dimensions, we would somehow have to wrap the straight lines of the diagonals around each other to make that possible. Is that possible in the current scheme of things that we know of? Considering that we are talking hypothetically, if we took time as the fourth dimension and any one who has read the time space theory will be quite familiar with what it means by time being an dimension, suppose the two diagonals exist in different time dimensions altogether, never overlapping each other in a particular time instance can we still say construction of the above structure is impossible? I know the idea exists but can I build it?
Similarly we have constraints in architecting a software solution, we are constrained by the lack of dimensions in software engineering. When it comes to plumbing a software we are stuck with dimensions which are less that what we would like to have. Software is heavily dependent on what gets written hence it is prone to be buggy and fall short of standards which is the expected norm in pear industries like civil, mechanical and the automobile sector. All the core sciences are governed by laws which give them a predictability of behavior. Software has no laws to govern it, hence the predictability of a software code is unpredictable. Shine a ray of light and you know how it will behave in a environment where it has been observed before, write a piece of code and run it in an environment where it has run zillions of times before in test conditions and still it may fail for all you know.
Software architecting is a core science which is analogous with architecting any thing, it requires tying to known the unknowns to such an extent before a software is even attempted to be built that the unknowns remaining when we actually start the engineering part probably form a miniscule part and end up playing no major part in the failure of a solution. Software has to mature from need - engineering basis that it currently runs on to a need - architect - engineer basis to come up with application which do not fail at such regular frequency.
Industry norm for a application or product following the processes to meet the requirements have to be replaced with the processes followed for say launching a satellite or possible a heart surgery. Imagine opening up a heart for a transplant and realizing that the size do not quite match, or the blood groups do not match or for that matter the main heart surgeon jettisoning the operation theatre in the middle and someone else asked to take over to complete the patch.
Software in the next phase will mature where architecting a solution will find its due and solutions will be thought of first and then engineered rather than patched up as in most of the cases today.
The wheel of the software is yet to be invented, till then it’s a bumpy ride on a set of oblong tyres.
There have been innumerable ideas which have given a new course to the direction in which the world has moved. A wheel may be the mother of all inventions also laying claim to the earliest possible inventions known to humankind. A wheel was driven by the need for momentum and it has passed through various stages from a oblong rock in the earliest period to the composite spheres which we are now building for robots which can use them to travel on any surface.
This whole process of the solution for momentum can be segregated into 3 parts, the need which is the requirement for momentum between two finite points, an idea which foresaw motion and the engineering aspect which converted that idea to concrete elements like a wheel.
The engineering has gone through many iterations in from the ages when humans may have traveled a bumpy ride between the caves on a night out of home made beer to the work of art wheels we see today on some of the vehicles made of carbon composites and having the capacity to bear speeds which routinely break the sound barrier. What has stayed consistent though is the need which is momentum and an idea which fulfills that need.
Software as different it appears to be to the layman also follows the principle of a core science namely software architecting and software engineering. Given the need for a solution a software can be architected and then engineered. It is similar to a dam being visualized, architected and then built or for that matter an automobile being visualized, designed and built. Software also supports visualizing, architecting and then engineering. If only we get down to identifying and following the process in the true sense.
A building wrongly built is visible, a dam wrongly architected is a fatal danger, a automobile designed in an ugly fashion is open to ridicule but a software which is wrong architected or engineered stays out of the sight by the inherent quality of software which gets it treated differently.
An application shutting down on a daily basis draws at most our curses while if our car did that ahem, would not like to be in the shoes of the person who sold the defunct vehicle in the first place.
Software as we know today is patch built and not architected, we have so many frameworks floating around but not a single one stresses on the need to visualize and then engineer. We have so many unknowns in the design of an software when we start the actual construction that we end up building a system and then patching it up to make it work the way we wanted it to be built like.
Visualization is a science where we can think of out of the box solutions, ideas which can range from the unorthodox to the mundane. Architecting is like a science which runs like a dream, which is not bound by the dimensions and constraints known to us. How many times have we had brainstorming sessions in our teams when faced with a requirement which would either take too long to create and too costly to implement. How many times have we shouted down someone who had the gumption to stick the neck out and propose something radical or something too simple to be considered a solution. Some of the answers out there for questions which are hard to understand are simple in nature. We do not need the unnecessary mumbo jumbo and expressions running into a vocabulary of a 3 times doctorate holder to always solve something complicated. We pour resources in time, money and efforts solving bottlenecks without out seeing if there is an alternative to the idea itself. Imagine if human mind did not have the inherent quality to find alternatives we would still be driving vehicles on oblong tyres - ouch…
A messy rendering of a 3-Dimensional object which can only be rendered but not constructed.
Imagine trying to build everything we could possible think of, imagine trying to build the image above in the constraint of 3 dimensions, we would somehow have to wrap the straight lines of the diagonals around each other to make that possible. Is that possible in the current scheme of things that we know of? Considering that we are talking hypothetically, if we took time as the fourth dimension and any one who has read the time space theory will be quite familiar with what it means by time being an dimension, suppose the two diagonals exist in different time dimensions altogether, never overlapping each other in a particular time instance can we still say construction of the above structure is impossible? I know the idea exists but can I build it?
Similarly we have constraints in architecting a software solution, we are constrained by the lack of dimensions in software engineering. When it comes to plumbing a software we are stuck with dimensions which are less that what we would like to have. Software is heavily dependent on what gets written hence it is prone to be buggy and fall short of standards which is the expected norm in pear industries like civil, mechanical and the automobile sector. All the core sciences are governed by laws which give them a predictability of behavior. Software has no laws to govern it, hence the predictability of a software code is unpredictable. Shine a ray of light and you know how it will behave in a environment where it has been observed before, write a piece of code and run it in an environment where it has run zillions of times before in test conditions and still it may fail for all you know.
Software architecting is a core science which is analogous with architecting any thing, it requires tying to known the unknowns to such an extent before a software is even attempted to be built that the unknowns remaining when we actually start the engineering part probably form a miniscule part and end up playing no major part in the failure of a solution. Software has to mature from need - engineering basis that it currently runs on to a need - architect - engineer basis to come up with application which do not fail at such regular frequency.
Industry norm for a application or product following the processes to meet the requirements have to be replaced with the processes followed for say launching a satellite or possible a heart surgery. Imagine opening up a heart for a transplant and realizing that the size do not quite match, or the blood groups do not match or for that matter the main heart surgeon jettisoning the operation theatre in the middle and someone else asked to take over to complete the patch.
Software in the next phase will mature where architecting a solution will find its due and solutions will be thought of first and then engineered rather than patched up as in most of the cases today.
The wheel of the software is yet to be invented, till then it’s a bumpy ride on a set of oblong tyres.
Comments