stevedoria.net

First Law of Holes: When in a deep hole, stop digging.

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.

On Thanksgiving Vacation

November 21st, 2010 Posted in Personal Development | Comments

2010 has been a very busy, yet brutal, year. I have used more vacation hours this year than any of my previous years of employment. By leveraging the Thanksgiving weekend, I am able to have nine contiguous days of rest from work at the cost of three vacation days. As is the case for sleep, having a nice contiguous amount of time for a vacation is more fulfilling than interrupted short bursts of rest. I am relaxed, and I am feeling pretty good.