The engineering of software

I am a 'software engineer' not in my designation but as a term that describes my work. At least that is what I strive to be.

Those two words 'software engineer' actually imply a person who can instill an engineering discipline into creating software. Developing software is itself a demanding task and most often it is common to just leave the engineering part of it as a name tag.

Why is this so and is it important that we at least see the issues clearly. G.K.Chesterton once remarked
'It is not that they cannot see a solution - It is that they cannot see the problem.'

One of the problems we are still trying to understand and solve is creating a mathematical representation of good accuracy that models the complex structure and behavior of software instructions. These include the type systems, concurrency models, knowledge models and reasoning.

Can you write software without all this - well you can. The difference is you can write software but you can never accurately derive and prove program characteristics until the program is written.

It does not matter how long I have been writing software without engineering. It is important at some point to realize that estimation, understanding and verification of software are impossible without further investigations into analytics or simulation. Empirical observations and knowledge of historical projects is only a small first step. Further, safety and better use of software will result when we are able to model program characteristics in a formal representation and then even verify whether actual programs conform to those characteristics.

The areas we need to investigate are a language for program representation that has high fidelity to programming languages but is more formal and concise. It should not be bound to normal structure found within implementations of programming languages like type rules.

This representation can then rendered in either human readable algorithmic forms or as visual diagrams (UML). The final breakthrough is creating a computational task that can 'understand ' a given concrete program and create a representation. This representation will be complete not only in static structure and interaction (UML achieves this) but also in semantics and flow.

This idea is quite old but is still valid and worth pursuing.
Can you see? - that is the question.