Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Language
Communication requires language. Within a development team, different sub-teams use different languages. Some of these languages are textual, others are graphical, and still others are more mathematical in nature. There are languages for expressing requirements, defining interfaces, defining database tables, communicating analysis and design models, describing algorithms, describing patterns, and a myriad of different programming languages for communicating instructions to a computer. Much of the work of a development team involves translating from one language into another. And then, of course, to add to the mix, there are communications channels and languages required to communicate with customers, users, and sponsors of the project.
Each time we translate from one language to another there is a potential to lose information or communicate the wrong information. Errors can occur when converting statements made during verbal interviews to structured requirements and diagrammatic models, adding documentation to the models, developing persistent storage models, and even creating the code. If information is not accurately transferred at each of these "interfaces," we have the potential for building the wrong system. Therefore, we want to keep the number of translations of information to a minimum and automate as many of the translations as possible to reduce the chance of information being lost.
To further complicate matters, at each step along the way, the people involved in transferring the information may not know what they need to communicate. For example, the users defining the system may not know what they really need. They may end up describing task steps or symptoms of a larger problem without actually communicating the needed functionality. So not only can we make errors in translating the information from one form or medium to another; we may not even be translating the right information! Therefore, a good process uses numerous feedback loops to provide validation and verification as often and as early as possible.
Another big problem preventing communication is the fear of being wrong. If a user, manager, analyst, or developer is so scared of being seen to have made a mistake that he or she withholds information, clear communication is obviously compromised and the error is often compounded over time. We should have accountability within a project, but our software development processes should encourage and support an environment of trust and responsibility rather than one of suspicion and fear of recrimination.
A software development process describes what to communicate, when to communicate, how to communicate, and to whom to communicate. (Most process descriptions won't tell you why; this is normally left for someone to write a book about!)