Tags
computing theorems, formal verification, guidelines, innovation, inspirations, methodologies, models, principles, processes, software, tools
Unlike other disciplines, software development products cannot be fully validated before they are built. When you design a building or a bridge, applying physical models and laws, it is possible to guarantee that the construction will not collapse under normal conditions and excluding construction issues like concrete composition or the design metrics not been respected. This allows to undertake very complex architectural projects that otherwise would be very risky to assume. In summary, because there is science behind, mankind has the means to achieve mastery in construction.
Software engineering has the aspirational objective of achieving this maturity but unfortunately it is not possible to create a model of what you are building without building it. The model itself, once finished becomes the deliverable. The closer comparison would be moving your software from your development environmet to your production environment, with any intermediate steps you may have (test,preproduction).
To overcome this, and provide the discipline with all kinds of warrants during every step of the implementation, software engineers have come out with a wide variety of models, principles and patterns that guide and inspire them throughout the process, bringing light to a task that otherwise would remain uncertain in terms of achieving its goal and mystical in the means that intervene.
Even when this is true, gurus, ideologist, visionary and Illuminati in the field have created a terminology to keep the knowledge in the initiated circle.
Hence, we have that OOP, a paradigm in itself, should be SOLID, while within our GRASP, DBT must be ACID what can be weird for newcomers. You better adjust yourself from the beginning being TDD and/or BDD, maybe modularizing following an AOP approach.
In IT security you must remember AAA to have a CIAAN service that you manage using a PDCA iterative cycle that maintains your BCP in sync with your business.
The list is endless even if we keep it limited to Programming paradigms. This doesn’t mean that the rest of science and engineering is free of paradigms that can not be elevated to the category of laws or theorems nor rejected as partial or wrong.
The future though is promising, if we observe scientific paradigms they are at the boundaries of the discipline. It´s not adventorous to consider paradigms progress pushers and hence responsible for any evolution.
The difference is that computer science is a relatively young discipline and paradigms outnumber theorems.
And while it could be contradictory, most of the theorems (Turing Completeness,P vs. NP,Halting Problem, Turing Test) are not relevant to the more daily tasks and problems a computer engineer may require, although some appear or should be considered more often than intruders in the profession may want to admit.
Also, efforts have been made to provide powerful tools for more regular programming tasks. Formal verification lies in this category, but reality is that we don’t see it used very often. Its complexity make it overwhelming for many tasks that would benefit from using it but it should still be kept in mind as a resource.
While computer science doesn’t reach maturity, paradigms are the crutches that help us get to our destination, the baby walker that guides our intuition and feeds our experience to achieve our goals in computer engineering and software development. They are our best option while the Vademecum for software development is not validated, approved and published.
Ideas for Project Management 