Python DevCenter
oreilly.comSafari Books Online.Conferences.


Software Engineering for Everyone
Pages: 1, 2

Collegiality: community accomplishment

Another crucial aspect of engineering is collegiality. By collegiality, I mean being a willing, self-conscious participant in a communal activity. Software development engages participants distributed across space and over time. Teamwork is part of collegiality. Scholarship is another. The key thing to recognize is computer software is a community accomplishment. Everyone who contributes, in any way, brings something that wouldn't otherwise have been there.

There are two simple practices for developing collegiality:

  • Eagerly acknowledge the contributions that you find in the work of others.
  • Develop your work so that it is understandable and available to others without you.

In short, borrow, add, and give it away.

I grew up on a steady diet of pre-Sputnik science fiction. I say that Robert Heinlein taught me to read. In all of that reading, I thought of being on the moon or going to Mars as something that would be a personal, individual act. The reality of space flight and the magnitude of the enterprise that it took just wasn't the way I dreamt it would be. Today, I'm moved to tears by the magnificence of that undertaking and the contributions that so many people made to bring space flight to reality. Every detail and every contribution mattered.

Human activities of any scale are cooperative activities. As a young software developer, I had this conceit that I could do it all myself, relying on my innate creativity, and if those other jerks would get out of my way it would all be perfect. Now, I know that's hogwash, but I'm still sometimes caught wasting time before consulting someone else for assistance. I want the work I share to be perfect.

Work doesn't have to be perfect before it can be shared with others. The constructive observations of others will provide focus on essentials that are easily overlooked by someone immersed in a project. Explaining a program design to someone else provides insights into what I am doing that I wouldn't have had, even when the person I am having a walkthrough with doesn't say a word. I don't know why that is. It works so often that I simply trust in it.

A good way to share your work is to write about it. That includes sharing your writings as imperfect work in-progress. In my first dedicated programming job in 1959, ("Clerk Typist A" since they hadn't invented student programmer positions) the faculty member I worked for was creating a handbook of software. I was constantly frustrated in my struggles to write intelligible documentation for the programs we were gathering. Sticking with it, I learned what I have heard repeatedly since: the way to learn to write is to start writing.

Nowadays I incorporate documentation as an inseparable part of the design of programs. Assuring that a program is explicable is my primary test for conceptual economy of the software itself. Even when I am not building software for anyone else to use, I preserve the hard-won habit of documenting what I am doing as if it is intended for others to be able to use without having written it themselves. Truthfully, I don't ever think otherwise, because that someone else is often my forgetful future self.

Mastering programming is not a solitary activity, no matter how much we go through it individually. For it to work, we must be willing to submit our work to the adaptation and refinement of others. When I first met Donald Knuth, he spoke about some of the most beautifully crafted programs he had ever read and that inspired work he would later be renowned for. Early, handcrafted software became the inspiration for our generation of programmers because earlier programmers made their work available to study and adapt.

Accountability: What happened when?

The third element of software engineering is accountability. Accountability is providing an accounting of what happened, how it happened, and even why it happened. It's easy to overlook this common element of engineering and scientific disciplines.

When I dropped out of college in 1958, freshman calculus plus high-school drafting classes got me a job as an engineering aide at Boeing. I created graphs and charts from the output of computer models of aircraft behavior. Everything was checked, signed, bound, and filed. The engineers wrote everything down. Everything. The lead engineer and I studied FORTRAN together. This was my first contact with a power user. Rather than suffering with difficult-to-digest output that the software group was willing to provide, he demanded program results in the exact form needed for the analyses and engineering reports we were producing,. Although I resented the work's tediousness, I never feared riding in the Boeing 720 when it was later produced. This experience taught me the discipline of accountability.

In Watts Humphrey's Introduction to the Personal Software Process, students record their time and keep a log and journal very early. This becomes a progressive historical account of actual effort, including the ideas that were tried, the problems that were discovered, and how the course of a project evolves over time. It also provides insight to the engineer, scientist, or student about where activity is spent and how long it takes to accomplish things in a genuine, not imagined, workday.

The critical instrument of accountability is keeping records of what you are doing while you are doing it. Practice and strengthen the discipline of accountability by keeping notebooks and journals. And stick to it.

Failure: winning isn't always easy.

Accountability, collegiality, and predictability are the elements that help engineers succeed, but engineers don't always win. It's important to have room to fail. Predictability, for example, is a hard won skill. I may fail repeatedly before having predictability. It is not something you or I already know. Taking on a new area of technology or changing my tools puts that deficiency in my face. When I'm afraid of being incompetent, procrastination sets in, compounding the problem. I am awestruck at how incompetent today's great software engineers must have been willing to be, so that they could have the experiences that gave them mastery at predictability.

Today, open source projects carried out over the Internet can provide direct experience in all aspects of predictability, including what happens when you lack it. There is no safer or more satisfying place available to the willing newcomer. Find an Internet study group or volunteer for a simple piece of a group project on the Internet. Most open source projects need people to practice installing and using the tools, provide information about problems, and provide documentation. All contributions are appreciated. Open source development makes the perfect public laboratory. As you learn to program with others, experiment and observe your own development of the crucial elements of engineering. Remember to log both your successes and failures. You will become a better programmer for doing so.

Dennis E. Hamilton is an international consultant on the creation of document processing systems.

Return to the Python DevCenter.

Sponsored by: