The invisibility of software and the coding warroom

Software is one of the few things built by humans that is incredibly hard for us to fully see. This is true during the construction process and after it is 'complete' (one problem is that good software is never really complete- new features are constantly added, it is made easier to use, and it gets fixed when bugs are found). It is very difficult to get a sense of how all the pieces fit together.

When asked by a layman to describe how modern software (i.e. large software) is built I like to use an analogy. Building a large piece of software is like building a skyscraper where the construction workers can only work at night and each worker has only a small flashlight to guide them. One can only see about ten feet in front of them at any one time.

We write code on small screens and can only see a tiny fraction of it at any one time. We use certain models to help get different perspectives of our systems but we cannot pick up and examine the pieces and see how they fit together like we can with almost every other thing that is engineered.

It is even harder to visualize how software changes over time. With time lapse photography one can see how a skyscraper evolves but the same is not possible with software. How does one see how some exceptional work has evolved from the early beginnings to a mature and extensible solution? Most of the code I am proud of was grown over many iterations. There is usually a good story about how the code changed over time but these stories rarely get told to anyone and almost never get written down anywhere. They stay in our heads for a little while but they inevitably escape into the ether.

In order for developers to grow and learn we must open up for examination how we do our work. One would think that knowledge workers, because of their ability to gather and manipulate data, would excel at capturing and presenting this information to their peers. However, if you look at some of our tools (our version control systems in particular) we are pretty bad at it. For example, some of the most valuable thought work that we do happens at the whiteboard. Inevitably, it gets erased shortly after we create it. We rely on our memories to store much of this valuable information and the stories about how the work has evolved. I think a more reliable storage mechanism should be used.

I have often wondered what it would be like for software developers to project their work in 'warroom' like environments. Imagine groups of developers working together where everyone could see what is happening by members of the team. This would certainly help (at least partially) solve the 'invisibility' problem by expanding our view of the system beyond the 10 foot limit.

So, you think you're a good software developer? Who have you taught lately?

The Learning Dilemma

The day one graduates from college with a degree in computer science is usually a joyous day. It is on this day, however, that most realize that their educations have really just begun (I know I felt rather unqualified at this point). All software developers have decades worth of learning in front of them. In no other field is this more true than in computer science. Our field is so new and so important that one cannot expect to make a real contribution without a serious commitment to learning over an entire career.

This knowledge will be hard to acquire, however, because there will be no more lectures, formal assignments, tutors, or professors to guide them along the right path. For a professional developer, most learning takes place while building a real system. To make matters worse, knowledge workers have an additional burden- it is extremely hard to see how others do their work.

Working on a computer is a mostly solitary activity. We sit in front of our machines and do our work. Rarely, do we invite others to see what we do or how we do it. There may be a great developer sitting three feet away from you but it is unlikely that you will ever learn anything from watching them work. Or, you may be that great developer, and you may be surrounded by lesser developers who want desperately to learn what you know. Because of the nature of work done on a computer it is not entirely clear that your knowledge will spread to the people geographically close to you. Compare this with sculptors sharing an art studio and you will see that knowledge workers are at a disadvantage.

Good Developers Teach

We have excellent teaching resources available to us, these are our best developers. There is a dangerous misconception that our 'rock star' developers are too valuable to slow down to help teach the rest of the team. I would argue that if you want to call yourself a good developer you must:

• actively teach the people around you to become better
• actively seek out learning experiences from others with different experiences

In other words, it does not matter who you are, everyone on the team should be held accountable for a certain amount of teaching and learning. Developers should be evaluated on how well they do both. This is something that can easily be measured. Further, team members can help each other achieve these complimentary goals by being active teachers and learners.

Our best developers should be given a venue to teach what they know. Management should survey the team to find the most obvious and high value deficiencies of the majority that can be remedied by the minority. The lesser developers on the team may not be able to teach the rock stars many things about software development but they can teach about other experiences that might be of value. For example, I learned a lot about the culture of China from a chinese co-worker of mine who was an electrical engineer. This knowledge has colored my view of offshore manufacturing and engineering ever since.

My advice for computer science students who are still in school is to try and land a job as a department tutor. You will learn how to teach others by listening to how your clients perceive their problems and coming up with suggestions that match their needs. You will take this skill with you into the 'real world' where it will be put to good use. Interestingly, since people perceive things differently and have different backgrounds you will most likely learn things from the people you are trying to teach! This is something that always amazed me while I was a tutor and still amazes me today as a college professor.