Excellent guess, Kreskin. Wrong, but excellent.


December 16th, 2011 Posted in Software Engineering | 1 Comment

Lately, I have been involved with optimizing code to improve execution time. I am still becoming familiar with a large and complex software system that is used by a multitude of end-users. Because my knowledge of the system is limited and people are dependent on the system, the scope of my modifications is focused on functions rather than components, modules, or subsystems. Profiler results present candidate functions that may benefit from optimization. The profiler results that I have encountered in my optimization efforts are consistent with the 80-20 rule, where 20 percent of the code is responsible for 80 percent of the execution time. These are the functions that I focused on, since they had the greatest chance of improvement.

I have had to optimize code toward desired characteristics in other projects. In other projects, I have had to optimize for space as was done in the implementation of memory built-in self tests for custom peripherals on an Infineon chip. Space was scarce in this situation, and it was fortunate to have control words, which manipulate the custom peripherals, that allowed the use of simple compression methods. Though the decompression of the custom peripheral instructions added to the execution time, the added execution time was acceptable as it allowed the built-in self test code and data to fit in the limited memory space.

In another situation that called for optimization, a tradeoff between data NVM and instruction NVM was present. In a Harvard architecture, data and instruction memory are separate. This is different from architectures that allow execution of code in memory that is also used for data. When the data NVM neared exhaustion in a previous experience, minimization or optimization of data NVM use became required. In this situation, data NVM usage was minimized by initializing variables with variable assignments. The variable assignments were implemented by the processor with “load immediate value” operations that placed the desired values into variables represented as registers. The variable assignment code resided in instruction NVM as opposed to copy sections that reside in data NVM.

At times, there is a need to sacrifice space for reduced execution times. Sometimes, space is scarce and an increase in execution time is acceptable. Other times, there is an exchange between the memory types. There is also a possibility that optimizations result in reduced space and execution time. In my view, optimization can be seen as the management of tradeoffs.

With the gains achieved in my current optimization efforts, I am wary of the possibility that premature optimization may be considered implicitly encouraged. As Knuth is credited in saying, “premature optimization is the root of all evil (or at least most of it) in programming.” A lot of time may be wasted by optimizing a solution that is later replaced. A great amount of time may also be wasted in optimizing code that consumes a very small percentage of the system’s resources. Premature optimization may also introduce complication or complexity to the implementation that adds difficulty to completion of the system and decreases the feasibility of meeting schedule constraints.

Although I disfavor premature optimization, the adoption of RandomSort() or approaches of similar quality with respect to their situations should be avoided. The optimization of an inefficient approach to a problem is a totally inappropriate allocation of valuable resources. A balance between premature optimization and efficient algorithm selection must be maintained. When it comes to a decision between a prematurely optimized solution and one that is good enough, I encourage the adoption of a good enough solution that is implemented in such a way that an optimized solution can be easily substituted if a need arises. This allows timely implementation of the system as well as a starting point for profiling and incremental refinement.

RandomSort() is a function that shuffles the elements of a collection randomly, and checks if the elements are ordered. The process is repeated until the elements are ordered.

Potential HP Remote Exploit

December 8th, 2011 Posted in Security | Comments

I remember my first computer. It was a standalone system that booted directly to the Microsoft DOS prompt. There were no logins nor passwords. There were no real security measures to protect files on disk or processes in memory. Floppy disks were the primary means of transferring data between computers. Bulletin board systems were popular at the time, but without a modem, a computer could not be connected. There was no concern, aside from a burglar taking my computer, of data theft and security.

As more and more devices are added to the Internet, security becomes increasingly important. There has been news lately of the potential for remote exploits in HP printers. The addition of printers, phones, coffee makers, security systems, and other devices to a network enlarges the attack surface for that network. A larger attack surface provides an adversary with more potential vulnerabilities for exploitation. An HP representative can downplay the possibility of using malicious code to remotely start a fire, but this should not distract people from the fact that malicious code can do destructive things with less fanfare such as silently forwarding copies of confidential information to adversaries or identity thieves. It is important that network devices, specifically printers, keep up with current security practices. And, it is important that we continue to implement systems that are secure by default.

Wherever the Wind Blows

August 24th, 2011 Posted in Personal Development | Comments

The winds of change have scattered my team among several companies. The cohesive forces experienced between team members at my previous company have resulted in groups of people finding themselves working in new environments with others of our previous company. Two former teammates have relocated to a semiconductor company, and two others took up positions at an aerospace company. I joined two colleagues from my previous company to be a part of another company. Other groups have similarly formed, and they work together at other companies.

Having been at a small technology company has allowed each team member to develop skills that are highly marketable. With each team member interested in developing their skills, an arrangement evolved where an engineer earned experience in all phases of the development life cycle. The software development team, for example, rotated the responsibilities of designing, implementing, and testing software components. At some point during the projects, the latest additions to our team would be responsible for critical and complex parts of the systems. Each member gained experience delegating work and tracking the progress of their modules. The team as a whole was also responsible for integrating these software components to yield the final deliverable products. This environment, with its opportunities for self-development and enhancement of professional maturity, was fostered by an effective managerial style practiced by experienced management.

I have interviewed at numerous companies, and received several offers. My interview experience and results are shared with many of my former teammates. The former company left us in a stronger position that allowed us to select our next company among those that would give us opportunities. While I was engaged in interviewing, I was interested in the team that I would be joining, the type of projects, and the environment overall.

I am thankful that many of the people with whom I interviewed were very candid. One company explained to me that being at the office for at least 60 hours per week as well as being reachable while away from the office was expected and typical. Another company informed me of their lack of process and documentation, and gave me a warning about a challenging transfer of knowledge and steep learning curve. The management of this company expressed interest in increasing formalism, and I was willing to be accountable for effecting positive change, but the environment seemed too challenging to encourage change without real authority. Ultimately, my selection of an opportunity depended on the team, the company, and my interests. My former teammates have also made their selections based on their preferences.

It is here, then, that I wish my former team members the best of luck in their endeavors. I hope that their careers lead to achievement, personal fulfillment, and betterment of society as a whole. And, I would strongly consider taking the opportunity to work with any of my former team members in the future.

Do Not Disturb: Working

December 28th, 2010 Posted in Software Engineering, Team Management | Comments

Jason Fried gives a talk entitled Why Work Doesn’t Happen at Work. He presents his observation that people feel more productive when they work at places other than their office, into which companies invest heavily with the hope of maximizing worker productivity. He concludes that people find other places for work more conducive to productivity, because those places have fewer involuntary distractions.

Fried draws a similarity between sleep and work by claiming that constant disruption of these tasks causes similar effects. Constant disruptions reduce the positive effects of both tasks. He highlights two significant sources of work disruptions and identifies them as M&Ms: managers and meetings.

To make the office a place where more people feel that they can get a lot of work done, Fried makes three suggestions to minimize constant disruptions to work. He encourages managers to foster a work environment that uses asynchronous forms of communication such as email or instant messaging. Although these forms of communication are also a source of distractions, the recipient of the communication can choose a convenient time for the distraction. Fried also recommends adopting a company policy that insulates workers from disruptions by barring communication between workers for a specified period. He suggests that it be labeled “No Talk Thursdays” or something similar. Lastly, he proposes the elimination of meetings. The issues that are typically addressed in larger meetings can potentially be resolved through emails between a few individuals.

I have labeled the impact of disruptions on work as “context switch overhead,” which is a phrase commonly used in discussions on multitasking operating systems. Recognizing the resource intensity of a context switch allows the value of predefined periods of uninterrupted work to be apparent. Using email, and instant messaging as needed, for communication allows workers to schedule convenient times for these disruptions. These recommendations are fairly easy to accept.

Certainly, some development teams will have trouble adopting Fried’s last recommendation, the total elimination of meetings. Latency in email responses are a possible cause of schedule slip. In extreme but not so rare cases, delays in or lack of communication are sources of work stoppage. A weekly meeting, one that Fried seems to oppose, is a good mechanism to allow all team members to coordinate their work efforts. Though meetings are set to begin at particular times, there is no reason that meetings cannot terminate before their entire allocated 15-minute blocks are used. The rigid adherence to using all of a meeting’s allocated time, as observed by Fried and used by him to justify his suggestion, is not required nor recommended. Because such adherence is not always practiced, absolute elimination of meetings is not justified. Unlike Fried’s development experience, I have had the experience of developers calling meetings between themselves that resulted in allowing each developer to more effectively focus their efforts.

Judging a Book by Its Table of Contents

December 23rd, 2010 Posted in Personal Development, Software Engineering | Comments

I stumbled upon a draft of a book on programming languages, which from a look over the table of contents seems to cover topics for a compiler book. Robert Harpers’s home page links to his book, Practical Foundations for Programming Languages. Whenever I find the time to read up on programming languages and compiler, I can find my local copy here.