Consequences of lessons not learned
Aged software companies started out with great products for their time. As hardware evolved COBOL and FORTRAN reached the age of retirement. While the congress has turned the age of retirement into a mirage, it has no authority over the retirement of programming languages.
Newer programming languages sprang with isolated attractive features. Over time, software companies were lured into writing extensions to their products in a variety of languages. Now they have to deal with the reality of having to maintain large applications written in multiple languages.
Soon it was bitterly realized that having engineers for each language is not profitable. So the companies started to send their engineers to expensive training courses for new languages. This only resulted in planting more defects deep into applications with large customer bases. This phenomenon came to its peak around year 2000 and was overshadowed by Y2K and the collapse of Telecom.
The consequences of the above trend and the fact that lessons were not learned are reflected in job requirements. Now an engineer is expected to interact with all those languages, as well as platforms and SDKs, etc. The truth is that no one engineer can write reasonable code in two languages, over the same period of time.
How much would you trust an electrician who offers to fix your plumbing problem? How about a neurologist who wants to operate on your heart? Either extreme is undesirable. We may go along with the electrician only because his actions are on objects other than our physical body.
Each language takes years to master and only a few months to forget. Now add to that the ever changing technologies and you should not find any surprises in the contemporary state of software development.
The unsupported claim is that, the engineer is not writing new software, just debugging an existing well-written product. Well, the neurologist is also interaction with a well-evolved physical body when trying to operate on your heart. Thus, if the state of the product matters, a neurologist is considerably more qualified to perform the surgery than an engineer trying to debug a well-written product in multiple languages.
The more significant issue is that the sum of all the languages used in a product leaves huge gaps open for the deployment of third party libraries, scripting languages, SDKs and a whole lot more. Even with all of that, engineers must fight threading, synchronization, sockets for client-server models, and so on.
That is where Z++ will save software companies very big, indeed. All these mysterious bugs suddenly disappear because Z++ automates the entire nuisance and presents it in the familiar object-oriented syntax of C++, and then without dependence to any platform. No SDK, no third-party library, just a scientifically designed superset of C++ for platform-free distributed software development.
Newer programming languages sprang with isolated attractive features. Over time, software companies were lured into writing extensions to their products in a variety of languages. Now they have to deal with the reality of having to maintain large applications written in multiple languages.
Soon it was bitterly realized that having engineers for each language is not profitable. So the companies started to send their engineers to expensive training courses for new languages. This only resulted in planting more defects deep into applications with large customer bases. This phenomenon came to its peak around year 2000 and was overshadowed by Y2K and the collapse of Telecom.
The consequences of the above trend and the fact that lessons were not learned are reflected in job requirements. Now an engineer is expected to interact with all those languages, as well as platforms and SDKs, etc. The truth is that no one engineer can write reasonable code in two languages, over the same period of time.
How much would you trust an electrician who offers to fix your plumbing problem? How about a neurologist who wants to operate on your heart? Either extreme is undesirable. We may go along with the electrician only because his actions are on objects other than our physical body.
Each language takes years to master and only a few months to forget. Now add to that the ever changing technologies and you should not find any surprises in the contemporary state of software development.
The unsupported claim is that, the engineer is not writing new software, just debugging an existing well-written product. Well, the neurologist is also interaction with a well-evolved physical body when trying to operate on your heart. Thus, if the state of the product matters, a neurologist is considerably more qualified to perform the surgery than an engineer trying to debug a well-written product in multiple languages.
The more significant issue is that the sum of all the languages used in a product leaves huge gaps open for the deployment of third party libraries, scripting languages, SDKs and a whole lot more. Even with all of that, engineers must fight threading, synchronization, sockets for client-server models, and so on.
That is where Z++ will save software companies very big, indeed. All these mysterious bugs suddenly disappear because Z++ automates the entire nuisance and presents it in the familiar object-oriented syntax of C++, and then without dependence to any platform. No SDK, no third-party library, just a scientifically designed superset of C++ for platform-free distributed software development.
Labels: client-server, distributed software, platform free, synchronization, threading, Z++
posted by Dr.Z. at 7:30 PM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>