Software Creation Mystery -

Software Development is The Flow of Ideas. The Rest is Secondary

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).

Idea Flow

Lifecycle of the most software projects:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. Frequent face-to-face communication is the best way to understand ideas.
  3. 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

  1. 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.
  2. They are smart, self-disciplined and creative.
  3. 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

  1. 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.
  2. Simplicity of ideas – people have very limited capabilities to absorb and remember complex ideas. Simple ideas will reduce translation losses and enhance understanding
  3. 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.
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.

AddThis Social Bookmark Button AddThis Feed Button


I’ve seen these games of Chinese Whispers where requirements change from layer to layer (User -> Customer PM/Analyst -> Software House PM -> Software House BA -> Developer.
The biggest problem / challenge I see however in doing the above is to find people who are capable of communicating with the customer, understand the business logic and develop the code. They exists but are the exception rather than the norm.

Comment by Ingo | July 23, 2007 2:30 am

It is not simple. However,
If developer cannot communicate with people and understand business logic, it is a problem anyway. If developer doesn’t want to communicate or understand, it is still a problem. A developers shouldn’t be a first class specialist in the business domain, but he should be able to grasp ideas and translate them correctly. Domain experts are still part of the team, but more as translators than commanders.

Comment by Andriy Solovey | July 23, 2007 8:24 am

[…] Software development step by step  […]

Pingback by still other links « Maimm’s Weblog | November 8, 2007 8:19 am

This blog have little value without you and your comments, thoughts and discussions. Please, leave your comments. You are welcome to debate and criticize any idea, but, please, don't attack other people. Thanks for your contribution!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting

Software Creation Mystery -
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License .