The TAO Principle in the Software Development Process

In larger companies or on the occasion of large ventures called projects, analysts are not one or two people but a group of people who develops requirements, business processes, specifies requirements. This group of people cooperates with designers, programmers and generally understood business. In such organizations, I observe two different ways of doing things. One, where modeling principles are not developed, and the other, where such modeling principles begin or have been functioning for a long time.

Where there are no rules, the quality of the analysis varies greatly. Every analyst is a different technique, every team is a different product. The resulting is chaos which does not help in communicating with stakeholders. It is also difficult to indicate particulars in the documentation prepared by a workmate.

Other organizations have rules that make the analyst know exactly what to do or seemingly know what to do. Sometimes these activities are inadequate to the needs or the problem being analyzed (it means redundant or too small) and sometimes lead to conflicts. I have encountered a few times a situation in which various teams (for example analysts and programmers) fought each other by pointing out inaccuracies in documentation, its deficiencies or non-compliance with the adopted rules or methodologies. This situation is undoubtedly not conducive to the product development, but also hinders work.

Where teams begin to form, like the analysts, designers or architects, developing work rules is very important. Smart work standardization is a standardization that not only takes into account notations, tools used, but also includes what I call the TAO Principle.

This principle refers to Taoism, which presupposes (in very simplified terms) self-acceptance, striving for peace of mind and harmony with the surrounding universe. In software engineering, under the TAO principle, I understand that the team is guided by: Tolerance, Autonomy and Responsibility.

Tolerance means that each of us perceives the world differently and also the built models, the created documentation of the system will usually be different than if we had built it ourselves. Each of us perceives the world differently from here and the models may be different. Tolerance does not mean that we accept everything. If you do not understand something, ask the creator of the artifact what he meant and do not judge in advance on what “crap” you have to work. Sometimes it is enough if recipients of the documentation tell them what is missing or needs to be improved. Often, artifacts do not require improvement, but the competences of both the creators and recipients of the documentation.

Autonomy is the right for each team member to select such tools (it means : diagrams and models) and such an abstraction perspective that, in his opinion, is adequate to the designed system at a given moment. It is the analyst or designer who has the right to decide what and how it will be modeled. Of course, you can and even need the requirements of a minimum  of artifacts, but you must also be open to the fact that our findings do not cover the situation. It is worth determining what artifacts will document a given class of applications, because the analysis of the application developed by the team will look different when it is for example CRM and different if it is for example a business rules engine. Documenting the system out of the box that is parameterized it is another story.

Responsibility strengthens and limits autonomy because it doesn’t allow shortcuts. A responsible member of the project team tries to present the system model from as many perspectives as necessary so that it is understandable to all stakeholders. He also takes full responsibility for his design decisions and pursues a common goal with the whole team.

TAO is easy to use and requires no revolution in the organization. Sometimes you only need to take a deep breath and understand your colleague, your workmate. Where models are the heart of the specification, it is worth doing cyclical workshops where team members present their models (and other artifacts) and there is a room to discuss them from the point of view of the techniques used. These workshops are also a place where you can improve work standards, exchange knowledge and determine together, in a team, whether the artifacts used so far in a given situation, in a given type of application make sense. TAO is a continuous improvement of team competence and workshop.

More from my site

  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • Kanban Bottlenecks Queues and WIP limits, which I discussed in the previous posts,  make up a chief indicator of problems in the flow. They show bottlenecks and when they are going to form. Bottlenecks […]
  • My Favorite Perspectives in Enterprise Architecture Modeling On Open Group pages a number of ArchiMate perspectives are presented. Using them all in a given organization is an obvious misunderstanding. I wrote very often about the fact that in each […]
  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with each […]
  • Registration of Problems Identified During the Analysis I received an interesting question by e-mail: According to your knowledge, is there an object in EA that would be best suited for registering problems identified during business or […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top