Getting Things Right
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 email@example.com.
When my time came to be president of IEEE Computer Society, I didn't think I was quite ready for the job. I had risen very quickly through the leadership ranks and didn't know much about some parts of the society. I knew little about standards and less about our education board. I was worried that I might make a bad decision that would haunt my presidency. A mistake that I could not correct. However, as I got ready to take the position, a friend gave me a bit of friendly advice. "You don't need to get everything right," he said, "you need to keep the organization on the path of improvement."
Of course, he was right. None of us can get the right answer all the time. However, all of us are responsible for trying to improve our lot. In software engineering, that means following the cycle of continuous improvement. This cycle can be summarized in five steps: Design your system. Build your system. Test your System. Identify changes for your system. Repeat.
The idea of continuous improvement predates computer science and is generally credited to an engineer at American Telephone and Telegraph (ATT) named Walter Shewhart. Shewhart argued that no engineer could completely understand any system. Hence, all engineers had to be prepared for problems and had to have an organized process to improve any system. He identified the basic steps of the continuous improvement cycle. These steps eventually became one of the foundation for software engineering.
As we work in a binary field, in which things are on or off, true or false, that we sometimes get locked into the idea that things are either right or wrong. We tend to think about fixing things rather than improving them. We also forget that the cycle of improvement works for many kinds of human activity.
A good friend of mine, who I general call "Doug the Rocket Scientist", was always a good example for me of the power of continuous improvement. Doug was a computer engineer who worked on aerospace projects. For a time he was the chief engineer of a company that make a small but highly important part for the US Space Shuttle.
As the space shuttle program started to come to an end, Doug decided to form his own company. He had several ideas about how to generate electricity that he thought could be the basis for a good company. He took one of the ideas, prepared a presentation, and tried to raise money to start a company.
Doug gave his presentation to a group of venture capitalists in Los Angeles, a group of investors that specialize in new and risky projects. He got a round of applause from his audience. He waited to get an offer from the group but never heard anything from them. He then went to a second group of venture capitalists and got the same reaction. No one called him with an offer to help him start a company. He did it a third and then a fourth time. Each presentation went well but none of them brought him any money for a company. Finally, he called one of the venture capitalists and asked why no one was willing to fund his business.
"It's a simple reason," said the capitalist. "You have a great technical idea but we aren't interested in a great technical idea or even a great product. We are looking for a great investment."
With that statement, Doug started the process of continuous improvement. He worked on his plans to make them a great investment. First, he worked on his business plan so that he had a great idea for a company. Then he worked on his marketing plan to show that he could sell his product. Finally, he started recruiting a team so that he would have good leadership for his good company. Good technology. Good business. Good marketing plan. Good leadership. He developed each of those step by step.
In many ways, we are best able to use the process of continuous improvement when his becomes a habit of thought, an approach that we bring to every task. Instead of looking for a set of rules that promise to produce one perfect design, we use the continuous improvement approach to get a design that works well and can even adjust to issues that we could not identify in advance. It works for engineering problems, business plans, written articles and even careers.
Earlier this year, I had the opportunity to try to teach the idea of continuous improvement to the leaders of Eta Kappa Nu, which is a student honors society that is sponsored by IEEE. The IEEE held a retreat for the leaders of Eta Kappa Nu and assembled the top engineering students from around the globe. It was held at a college in Arizona and drew leaders from Florida, Brazil, Belgium, India, and China. (Though, at times, it seemed as if all the students came from the University of California.)
The retreat included both technical talks and career discussions. The students were highly interested in the career discussions. Most of them were about to graduate and were anxious about the future. They desperately wanted to be assured that they would get a good job, that they would have a successful career, that they would do well. For most of one morning, they listened to senior IEEE members talk about their careers and the things that these senior members had done to be successful.
The students listened attentively, took notes and even asked careful questions of the speakers but eventually started to get restless. The speakers were talking about a world that they didn't entirely understand. The students had spent their lives in an educational environment and understood exams, team projects, and group study sessions. All of them desperately wanted to do something important. Many of them talked about working with a group of their peers to do good. Time and again, they described a vision that was much like the story of Facebook that has been popularized in the movie The Social Network. They talked about living with a group of friends and forming a company, or building some infrastructure, or fixing the environment, or developing jobs in a place where no jobs were to be found.
Eventually, a number of these students drifted into the lobby of the meeting, grabbed chairs from neighboring rooms and started discussing the problem of careers. They hoped the elders in the rooms would have some rules to help guide their career decisions. A few of the senior members offered a few observations but most of the students knew that they were merely telling the story of their own career. These members could not assure the students that these stories were actually going to help anyone who was about to start a career.
We could not tell these students that they were about to go through a wrenching change. Soon, their school social circle would be torn apart. They would try to keep it together with the various tools of social media. However, try as they might, they would not be able to work in the same way no matter how often they turned to the tools of Facebook, LinkedIn or Twitter; Sina Weibo, Tencent, or Renren.
After graduating, these students would have to work for an organization that would have enough capital to finance their projects. They would need managers to allocate capital resources and marketing staff to fit their work into the market. They would have some colleagues who had never gone near an engineering school and others who would not only be older than college students but would also have children who had long ago graduated from college.
As much as we might like to have offered rules for getting through this transition from student to professional, from late adolescent to adult, we could not. There are no fixed rules that work for all generations. Those of us who started our careers during the early software age faced a very different kind of world than do current graduates. I was one of the very few in my class that worked with companies from other companies. Now we expect that all graduates are working in a global market and that all of them will somehow be involved with companies from outside their home countries.
There are some simple observations that you can offer students and we offered them all to the leaders of Eta Kappa Nu as we sat in that lobby. Be careful with your money. Expect that you might change jobs every two years or so. Anticipate that you will likely badly misjudge your first job. Be patient.
None of these rules will do much to prepare a student for their career. You can better prepare them by teaching them about the cycle of continuous improvement and getting them to practice it. You do this more by living it than by talking it. Plan. Do. Listen. Adjust. Repeat. These steps the foundation of software engineering. They are also useful when you are creating a business or starting a careering. They help students learn how to make good technology. They also teach them how they get things right.