Software development is the translation of a user need or marketing goal into a software product. - Wikipedia
Why it is so difficult to understand the nature of the Software Development? Because it is ideal and metaphysical. Software Development doesn’t stand on objective physical world, but deals with fragile and subjective world of human ideas. That is why Software Development is much more than Software Engineering - it just cannot fit into Procrustean bed of well defined requirements, processes and laws (maybe except programming for science or physical devices).
Lifecycle of the most software projects:
- People generate software ideas based on people needs. Humans have difficulty understanding what they need and even more difficulty to clearly explain it to others.
- Software professionals try to understand these ideas and communicate to each other. Before coming to programmers these ideas are interpreted (more often misinterpreted) by bosses, marketers, project / product managers, architects, business analysts, etc.
- Programmers are trying to translate these mutated ideas into the program code. Many of them are more interested in creating technical puzzles (or doomed to fight them) than in complete understanding of business ideas - often changing and sometimes illogical.
- People use this software. Does it meet their needs? How happy do you think they are?
How to improve the flow of ideas?
1. Effective Translation Process
Realize that software development is the translation of ideas or user needs. The process as good as it supports effective idea flow. Everything else is secondary - certainly, if the goal is to make users happy.
- The best solution is to decrease translation path and move programmers closer to the source of ideas by:
- physical proximity
- creating instant communication channels
- removing middle men - marketers, project / product managers, architects, business analysts - from the critical path. They still have important roles to facilitate and enhance ideas, but more as a catalyst than funnel.
- Frequent face-to-face communication is the best way to understand ideas.
- Adjust course often based on feedback. Frequent incremental delivery of the product allows to discover communication breakdown, reconcile misunderstanding and improve interactions.
2. Right People
- Developers become domain experts responsible for idea translation. They move closer to business, while keeping specialization in building programs. They form core part of diverse, cross-functional project teams.
- They are smart, self-disciplined and creative.
- They are independent and open minded. Members of the team effectively work and learn together. The collective intelligence exceeds any individual capabilities (see Wisdom of Crowds).
3. Shared understanding
- People should speak the same domain language, work with the same concepts and have the same assumptions. It is titanic work considering different backgrounds, specialization and knowledge of involved people. It is titanic work, because it is almost impossible completely understand people. It is titanic work, because we often don’t understand ourselves.
- Simplicity of ideas - people have very limited capabilities to absorb and remember complex ideas. Simple ideas will reduce translation losses and enhance understanding
- Program code as a mirror of shared concepts
- Code should be as close as possible to the original language of idea communication for easier mapping and tracing of ideas in the code. Therefore, shared language should be less specialized and be accessible for the large audience.
- Code should be well structured, clear and easy to understand
Good flow of ideas will make systems better and users happier. Bad flow of ideas will make systems unusable and users frustrated. What other aspects could influence quality of software development more?
Few quotes
Alistair Cockburn [Agile Software Development]:
Communication is never perfect and complete.
Such a thing is not even possible. Even assuming for the moment that you, yourself, know what you intend, the receivers of the communication must jump across a gap at some point and must do that all on their own.
The more different another person is from you, the smaller the communication gap that she can jump. You have to back up, explain basic concepts, and then work forward until she builds her own bridge of experience and understands what you are saying. There is no end to this backing up. No matter how much you back up, there is always someone who will not understand.
Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.
Peter Naur [Programming as Theory Building, from Agile Software Development]
On the Theory Building view of programming the theory built by the programmers has primacy over such other products as program texts, user documentation, and additional documentation such as specifications.
1) The programmer having the theory of the program can explain how the solution relates to the affairs of the world that it helps to handle.
2) The programmer having the theory of the program can explain why each part of the program is what it is, in other words is able to support the actual program text with a justification of some sort.
3) The programmer having the theory of the program is able to respond constructively to any demand for a modification of the program so as to support the affairs of the world in a new manner.
Eric Evans [Domain Driven Design]:
On a project without a common language, developers have to translate for domain experts. Domain experts translate between developers and still other domain experts. Developers even translate for each other. Translation muddles model concepts, which leads to destructive refactoring of code. The indirectness of communication conceals the formation of schisms-different team members use terms differently but don’t realize it. This leads to unreliable software that doesn’t fit together. The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.
Therefore:
Use the [domain] model as the backbone of a UBIQUITOUS LANGUAGE. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Peter M. Senge [The Fifth Discipline]:
“Mental models” are deeply ingrained assumptions, generalizations, or even pictures images that influence how we understand the world and how we take actions. Very often we are not consciously aware of our mental models or the effect they have on our behavior.
The discipline of working with mental models starts with turning the mirror inward; learning to unearth our internal pictures of the world, to bring them to the surface and hold them rigorously to scrutiny. It also includes the ability to carry on “learningful” conversations that balance inquiry and advocacy, where people expose their own thinking effectively and make that thinking open to the influence of others.
Source: Software Creation Mystery