The vice president for engineering gave me the usual response when I asked him how the IEEE Computer Society might be of help to his company. “Tell us where we should invest,” he said, while making a big gesture with his arms. “Tell me which technology is going to be important so that we can make some money with it.” I understood why he made this request, but felt that he really didn’t understand what the Computer Society did or how it helped his engineers do their jobs better. Ultimately, they would be able to answer his question better than I ever could.
The leaders of the Computer Society regularly meet with the senior managers of technical corporations. In this case, a couple of us had travelled to a technological center in Asia to talk about the kinds of services that we can offer to their employees. This vice president’s office was in the middle of the city and had a stunning view of the labs and buildings that supported software and hardware development. We had come to tell him about services such as corporate memberships, training classes, webinars, and a digital library. However, we also talk with corporate managers so that we can do our work better. We want to learn what these companies are doing and what issues they think are important.
Exchanging lessons learned
I learn a lot form these visits. I’m always a little surprised to discover that companies are struggling with problems that have plagued technology firms for 60 years: adapting complicated ideas for new products, meeting the demands of the market, ensuring that they can deliver high-quality services. At the same time, I almost always learn something that will be of use to our six operational boards.
Most of the work of the Computer Society is done through these six operational boards. They consist of volunteers who give their time and effort to the society. They conduct their business over the Internet and via conference calls. They usually meet together only once a year, usually at our June governance meeting in Seattle. The president gets to appoint the leaders of these boards, but I can tell you that the president really has less choice than you might think. The board leaders need to understand their boards and the work that they need to do. So you usually select volunteers who have served on the board before.
The six boards include one for membership, one that deals with educational activities, one that creates standards, one that develops products and services for our industrial members, one that creates and manages conferences, and finally one that oversees publication of Computer Society periodicals.
Every Computer Society president tends to think that the most important boards were the ones that they led. I was vice president of publications and so tend to think that the publications board is special. The board publishes 35 journals and magazines, maintains a large digital library, and publishes books.
Identifying technology trends
In some ways, our magazines do the best job of helping to identify new trends in computing technology. We have nine at the moment. They deal with topics such as security, graphics, pervasive computing, the Internet, cloud computing, and software.
A recent issue of IEEE Software magazine dealt with the issue of technical debt, a problem that affects software systems large and small. A software team incurs technical debt when it decides that it cannot fully implement the design for a piece of software. This usually happens when the company is facing a deadline and the organization’s management feels that it is more important to deliver the software to the customer on time than to wait until the software is fully implemented.
Sometimes, the customer is aware of the technical debt because the software does not work perfectly. In such as case, the system lacks a feature that was identified in the specification. However, more often than not, the technical debt is hidden within the software. The team does a simple implementation that cannot be easily extended. They fix a problem that limits the way that program operates. They fail to write all the documentation. They stop testing the system before they have exercised all the elements. These are all examples of technical debt.
Technical debt was originally identified 20 years ago but it has become more important in the last five or six years. The blogger Steve Cunningham argued that technical debt is a weight that slows the development of software and that it can come from both a conscious decision to stop work on the software or from minor decisions that are made by developers. These later decisions are particularly damaging because the lead developers don’t know that they exist.
Technical debt especially hinders agile software development, the process that tries to work rapidly, add small improvements regularly, and produce new versions of the software at short intervals. It forces the development team to fix the debt when it should be working on new features. “You can’t maintain a sustainable pace” in an agile development, explains one expert, “if you have technical debt.” (See IEEE Software, November/December 2013, p 29.)
Most development teams cannot easily identify technical debt nor devise a good strategy for eliminating it. In a special issue devoted to the subject, IEEE Software magazine showed how project leaders can use software tools to identify technical debt, and how they can use management strategies such as one called Software Quality Assessment base on Lifecycle Expectations (SQUALE). Perhaps most importantly, IEEE Software interviewed several software developers and asked them how they dealt with problems that were caused by technical debt.
Such interviews, be they in magazines, in conferences, or in any other format, represent one of the most important contributions of the Computer Society. They are very popular among our members because they are the voice of technical professionals talking to technical professionals. Like all forms of engineers or computer professionals, our members take great desire in learning from the experience of others and in turn, sharing what they have learned in their jobs.
Sharing experiences
Our visit with the vice president was not as successful as I might have liked. When we left his office with the beautiful city view, I felt that he didn’t quite understand what the Computer Society, or any professional technical society, actually did. I might have been able to give him a better idea of what we did if I had been able to take him to my next appointment, which was a conference in a city several hundred kilometers away.
The most important parts of the conference were not the organized talks but the intervals between the talks. In these intervals, attendees stood in groups and shared what they had experienced in their jobs and the lessons that they had learned. They were lessons that only they could express and only they could understand. They might be able to post these lessons on a blog or share them on a twitterfeed but they could best give voice to their ideas only in a forum organized by their peers through organizations such as the Computer Society. From those forums, they get a clearer sense of the state of technology, and get ideas that they can share with their managers and employers. In this indirect way, the Computer Society helps vice presidents learn about the newest technologies and determine where they should invest for the future.
About David Alan Grier
David Alan Grier is a writer and scholar on computing technologies and was President of the IEEE Computer Society in 2013. He writes for Computer magazine. You can find videos of his writings at video.dagrier.net. He has served as editor in chief of IEEE Annals of the History of Computing, as chair of the Magazine Operations Committee and as an editorial board member of Computer. Grier formerly wrote the monthly column “The Known World.” He is an associate professor of science and technology policy at George Washington University in Washington, DC, with a particular interest in policy regarding digital technology and professional societies. He can be reached at grier@computer.org.