Well, almost everything written in this course leads us to this point. If we follow methodologies, we use good tools and languages according to our criteria or those of the company in which we work, the product sells well, is well valued, etc. So why make changes? How to do them? Can we use the same development staff to make changes? How to maintain continuous changes? And we will try to resolve many other questions in this part. We will emphasize several proven ways of dealing with change.

But I warn you, the biggest problem when making Changes by Changes will be the programmers ourselves if we have not developed an effective Programmer Mind focused on changes and not only on new developments. There are people, programmers, who can only deal with new things and change "the old" they see as boring. Well, from years of experience, those who think this way are almost always linked to academic life, they say that it is almost "pure" and rarely have they been permanently linked to systems or programs in the long term. They have not finished developing their Programmer Mind, no matter how much academia they master and publish. They are like architects who design, but they never associate with the physical creation of what they have designed, much less with their daily life. Have you seen the documentaries of Great Engineering Errors?.

When buying classes or better when BUYING THE COMPLETE COURSE we can be in contact and perhaps I can help you as an advisor, consultant, or collaborator ...