Whenever a new requirement leads to enhancements of the system, quality processes are applied by our team to ensure they are implemented in the best possible way. At that moment, everyone works together to achieve the best solutions. During this task, we all usually reach a clear view of what has to be improved and even how to improve it.
Once the enhancements have been implemented, a feeling of satisfaction is followed by a very interesting thought: How were we able to live without this improvement? Was the system really worse then than now?
Furthermore, there is the feeling that we are approaching an optimal state. Since this happens almost every time an enhancement is developed, the fact that the system was actually imperfect before the introduction of an improvement, is not consistent with that feeling of reaching an ideal state. It is true that, because of the enhancement, something has made the system better than it used to be. But in that case, why didn’t this best solution come to us sooner, and moreover, is it possible that we will come up with an even better solution in the future?
We go through the same sequence of feelings in relation to the actual facts in many other areas – when a new workflow is implemented, or an old one is updated, when a new programming practice is added to our list, and so on.
The evolution of the software and, most importantly, the evolution of the team itself, is a cycle in which improving an aspect and pondering upon the changes made gives us room to improve even more in the future.
Therefore, the process of enhancing the system while growing as a team creates a future in which it is possible to grow and improve even more, although this idea might sound contradictory. The room for improvement can never be filled: it gets larger every time you reflect on what has been previously enriched.
This could be seen almost as an infinite stair that gets longer and higher as you climb up its steps.
These thoughts could lead us to conclude that new requirements motorize this cycle of evolution. But in that case, could we evolve without those requirements, or would we stand still on an apparently ‘unenhanceable’ system? The answer to this question is neither yes or no. Requirements can be a great starting point, but they are not the only source of dynamism. During the process of developing enhancements based on requirements, each new requirement in turn awakes ideas and internal requests that further empower the system and keep it alive and evolving.
At the same time, as the system gets better, users develop further capabilities to model their projects and, moreover, to generate more evolved requirements. So, at this point, the evolving cycle of the development process is being fed by the evolving cycle of the modeling process, and viceversa.
This is once more an example of how using better systems helps you think better as well!
That’s it for now. In the future we might rewrite this article because we are sure it will turn out so much better