Dark Ages of Software Development
Z++ makes it possible to design and develop sophisticated applications oblivious of platform idiosyncrasies. Thus, debugging a Z++ program is an abstraction in that you will be thinking about your design and its implementation within the Z++ language.
While crafting One-Touch Mail for J.P. Mobile (on Palm) I asked a senior engineer on my team to use the debugger and locate the exact sequence prior to a crashing point. I expected a good hour of work, and yet the engineer returned in about 15 minutes claiming that he had fixed the problem. He had simply located the point where the value of a particular object was coming in as invalid, so he hard-coded it to a valid value. The program certainly passed all related tests.
Prior to entering the industry I had taught as professor for over a quarter of century. With that kind of patience, I spent almost an hour with him to find the actual cause of the problem, and how to backtrack and fix it at a remote part of the code. Basically, the stack was being over-written so the return value from the call was coming in as invalid.
Vaguely speaking, Dark Ages imply the reign of superstition. The Dark Ages of programming, however, quite clearly imply the reign of confusion and chaos. Almost anyone who can type has theories on various aspects of software development. In particular, Microsoft/SUN/IBM and others are making waters murky by dumping languages and libraries in the hope of grabbing one another’s market shares.
The requirement of diversity of skill sets is the darkest aspect of software development, which rivals superstition. Interacting with multiple platforms is not the same as traveling and interacting with multiple cultures. A walk-in hacker’s familiarity with environment and finding quick fixes is the main factor in corrupting a well-designed product. Nevertheless, the hacker climbs the ladder and the actual expert will have to deal with him as yet another one of his bosses.
The diversity of skills in an engineering area defies the more intuitive notion of specialization. This is like a hospital hiring a general surgeon to perform heart transplant and brain surgery as well. Every aspect of software development comprises of a large number of skills that must be acquired over a long period of actual practice.
Some companies have the illusion that a young bright engineer will be able to do the entire work of a team by putting many hours into a project. Even in one area, it is extremely difficult to maintain focus over long intervals of time. Compare that to running a marathon every single day and beating Emil Zatopek.
Turning to debugging, we debug nature with theories and we have seen unusual results when we play God. We should debug software with exact knowledge, certainly not theory, or else we will be playing God with complexities beyond our comprehension.
The fact that you are engaged in a debugging session indicates that you have made a test that fails. Now, you can make theories, change the code and try the tests until it all seems to work. But you still can do better by stepping through the code and verifying the state of the program as it executes. This is even more important at design phase so you can see how your design responds to new ideas.
Stepping through a program and observing the states of objects is a verification process. When a program is not working properly, we use the same process to locate problems. In the latter case we refer to the process as debugging. Verification should be an integral part of software development as opposed to being the last resort to fix a bug.
Z++ is freely available from ZHMicro.
While crafting One-Touch Mail for J.P. Mobile (on Palm) I asked a senior engineer on my team to use the debugger and locate the exact sequence prior to a crashing point. I expected a good hour of work, and yet the engineer returned in about 15 minutes claiming that he had fixed the problem. He had simply located the point where the value of a particular object was coming in as invalid, so he hard-coded it to a valid value. The program certainly passed all related tests.
Prior to entering the industry I had taught as professor for over a quarter of century. With that kind of patience, I spent almost an hour with him to find the actual cause of the problem, and how to backtrack and fix it at a remote part of the code. Basically, the stack was being over-written so the return value from the call was coming in as invalid.
Vaguely speaking, Dark Ages imply the reign of superstition. The Dark Ages of programming, however, quite clearly imply the reign of confusion and chaos. Almost anyone who can type has theories on various aspects of software development. In particular, Microsoft/SUN/IBM and others are making waters murky by dumping languages and libraries in the hope of grabbing one another’s market shares.
The requirement of diversity of skill sets is the darkest aspect of software development, which rivals superstition. Interacting with multiple platforms is not the same as traveling and interacting with multiple cultures. A walk-in hacker’s familiarity with environment and finding quick fixes is the main factor in corrupting a well-designed product. Nevertheless, the hacker climbs the ladder and the actual expert will have to deal with him as yet another one of his bosses.
The diversity of skills in an engineering area defies the more intuitive notion of specialization. This is like a hospital hiring a general surgeon to perform heart transplant and brain surgery as well. Every aspect of software development comprises of a large number of skills that must be acquired over a long period of actual practice.
Some companies have the illusion that a young bright engineer will be able to do the entire work of a team by putting many hours into a project. Even in one area, it is extremely difficult to maintain focus over long intervals of time. Compare that to running a marathon every single day and beating Emil Zatopek.
Turning to debugging, we debug nature with theories and we have seen unusual results when we play God. We should debug software with exact knowledge, certainly not theory, or else we will be playing God with complexities beyond our comprehension.
The fact that you are engaged in a debugging session indicates that you have made a test that fails. Now, you can make theories, change the code and try the tests until it all seems to work. But you still can do better by stepping through the code and verifying the state of the program as it executes. This is even more important at design phase so you can see how your design responds to new ideas.
Stepping through a program and observing the states of objects is a verification process. When a program is not working properly, we use the same process to locate problems. In the latter case we refer to the process as debugging. Verification should be an integral part of software development as opposed to being the last resort to fix a bug.
Z++ is freely available from ZHMicro.
posted by Dr.Z. at 11:35 PM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>