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

  • Architect in Agile Team In the last post I described what I think about the role of an analyst in agile team. The second role that I would like to mention is the role of the architect. This role is defined in […]
  • Modeling of Business Processes in the Software Development Process Business process modeling is relatively common today. In many organizations, it is even done in two places :-). In a cell responsible for improving or supervising processes and in IT, […]
  • Implementation of the Methodology – Selection of a Modeling Tool In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build […]
  • Five Tips of Software Modeling My software modeling  is approach to software analysis based on reasonable diagrams. In this post I present my five tips of Software Modeling. Models evolve over time You can […]
  • When is it worth modeling in UML? For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the […]

Leave a Comment

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

Scroll to Top