Writing Computer Code Isn’t Difficult ~ Properly Testing that Code Is by Britt Storkson Owner, P2FlowLLC It doesn’t take much effort or knowledge to write code. Most coders use development software where the coder does not write code, but writes instructions in the development software which then writes the computer code the computer uses for them. This development software is sold and promoted as a way to speed up code production by requiring fewer programmer hours and less skilled (read: less expensive) programmers. But if the programmers end up writing ten plus times more code than necessary to get the job done, it doesn’t help much. Plus, unnecessary software greatly increases the likelihood of errors and omissions, which are correspondingly and exponentially harder to find and fix. Another downside is this divorces the programmer from what’s really going on inside the computer; it makes the simple complex and basically “chains” the programmer to that particular development software for the rest of his or her career. Required updates to this software (whether or not they are needed) and other necessary fixes provide the development software maker a steady revenue stream for years. It doesn’t make much sense, but it’s the industry business model right now. In any computer product, the “brain” and what all of this code is written for is called a microprocessor. The microprocessor is basically a very simple device. It contains no mysterious components or black magic. It mostly contains hundreds of thousands or even millions of tiny electrical switches which have two possible states. When switched “on”, the switch conducts electricity (allows current flow). When switched “off”, the switch impedes (stops) current flow. To make it work the coder or coder software gives the microprocessor a series of instructions in the correct order for the microprocessor to execute. At the microprocessor level, these instructions are very simple. A few of these instructions are: Add two numbers (values), subtract one number from another, test for zero, and instructions for memory management like go to various parts of the memory and copy data (information) from one memory location to another. While these instructions are very simple, they are also very fast. Each instruction can execute (be completed) in one microsecond or faster. That’s one millionth of a second - meaning one million instructions can be executed every second! Now that’s fast. It means you can get a lot done in a very short period of time. This dynamic has advantages and disadvantages. It makes storing and recalling information very fast, but this speed without adequate software-implemented stability measures can make for erratic and unreliable operation. Basically, this means that very little in the way of software changes can make very big impacts on just about everything. All of those programmers you have seen on TV gathered in a big room hunched over their computers frantically typing to fix a computer problem isn’t reality. Sometimes only one or two instructions or values related to these instructions need to be changed for everything to work right, but they must be the right changes in the right order. Other times, much more extensive software changes are required, but the basic routine still applies. The critical component here isn’t the software changes. The critical issue is thorough testing to verify everything is actually working as it is supposed to. This is what takes most of the time, or what should take most of the time. Recently, Honda motor company recalled thousands of automobiles for (their words) “inappropriate software programming”. This actually means they were recalled because of inadequate or incomplete software testing because that’s what it really was. To make any computer product “bulletproof”, you get everything working on the bench/in the lab, then move to field testing. This means you put the product in a real-world environment and live with it for awhile. There are always mistakes and problems that will need to be fixed in the process, and it’s fine as long as they all get fixed before the product is released to the public. The product needs to work right the first time and every time, under all conditions. Nothing less is acceptable. This takes time and patience, but the product is a lot easier (and much less expensive and embarrassing) to fix during the development stage instead of after it has been released for sale to the public. There’s a right way and a wrong way to do everything, and the right way to write and test computer code works every time. Britt Britt Storkson may be contacted via e-mail to michele@worldwidedrillingresource.com 19 WorldWide Drilling Resource ® NOVEMBER 2020
RkJQdWJsaXNoZXIy NDk4Mzk=