At its heart, I think software development is a communications business. In a nutshell, the goal of software development is to communicate user needs into computer processor instructions. That’s really all there is to it.

Now when you look at that communication path, there are quite a number of different skills needed to take the thoughts and desires of some population and make machine instructions out of them. This can be extra tricky for a revolutionary product or service where that user population doesn’t even exist yet and won’t exist until the instructions have been written and released to the world.

The reason we have so many different processes for software development is that they all try to tackle the communication process in a different way. A waterfall process tends to emphasize specialization, having people with similar skill sets collaborate to create clear and concise work products for downstream groups. People know that serial translation can introduce errors. If I take some English text, translate it to German, then Chinese and then back to English, it probably won’t be the same as it started. Anyone who has played the telephone game knows you don’t even need to add the complexity of translation. Simply whispering the same message down a chain of people introduces errors. These processes tend to emphasize reviews, checklists and rubrics to reduce those communication errors.

Agile methods emphasize feedback and tight control loops so those errors are caught early, favoring diverse members (including users) working side-by-side with frequent collaboration. Ethnography typically plays a big role as well. Users don’t necessarily know what to ask for. Even if they did, they might use a vocabulary that the developers don’t necessarily understand. Direct observation and interviews get past the user’s words to their needs.

For large systems, there is often no way to get certain types of feedback without spending many months of effort and many millions of dollars. But even it those cases, ethnography skills are still important as are journalism and anthropology.

I use the term “anthropology” deliberately for big or long-running projects in the sense that team members frequently need to understand decisions made long ago by people who no longer work on the project. The size and complexity of systems can be such that no one person really understands everything. Members have to sift through bits and pieces of various documents to understand how something should work or why it works the way it does. That is where journalism comes in. Having a journalist mentality facilitates this discovery and learning process. Traceability (like requirements traceability) is a frequently used tool that I count as a kind of journalist activity. But there are times when a project blog can be as valuable as a traceability matrix. Many processes are geared to capture the outcomes of decisions since that is the direct path to machine instructions, but the communication process can be better served with more context about the reasoning behind the decisions.

Developers need to wear that journalism hat as well. They are that “last mile” - the artifacts they write become the instructions that ultimately satisfy user needs. But those artifacts also need to be written for other developers. They need to be easy to understand and reason about. I like Ruby so much because I find it the easiest to write for both audiences, my human readers and my machine readers. But whatever language you use, and whatever size your project, make sure you have your communication skills adequately staffed. Software development is a communications business. It is as much about journalism, ethnography and anthropology as it is computer science, data structures and algorithms.