If you want something to die, leave it still
Building something relevant implies in most cases creating huge structures that depend on smaller ones (I really think this applies to all cases, but since I don’t know all the projects in the world, I don’t want to generalize).
The foregoing will have several consequences and that is that the larger the size, the greater the fragility. Just as Nassim Nicholas Taleb explained in this video to create large structures is to create a web of collaborations that makes it more fragile in comparison with small structures.
I understood this in my work. I’m in charge of the tests in software development. The idea behind software testing is to test pieces of software in the project fulfill the purpose for which they were created, that is, if we create a piece of software that consults a file in one format and returns another in a different format, the tests will verify that it does exactly that. The above sounds a bit trivial since if this piece of software did not do its job the project would not work, so it would be enough to fix it until everything is perfect; the problem is that the above works only in small projects and only when you are creating from scratch. How is this? Well, when a project is launched for the first time it usually has several areas that can be improved so it is common for these improvements to arrive over time, if it is a large project it is common that people who created the original software aren’t already on the development team so it will be up to other people to improve the codebase that was left to them. As you can imagine, it is normal that things do not turn out well the first time so that as soon as new people modify the code they will break things and it is very likely that due to these other things that depend on the first ones will stop working, again I want to emphasize that in a small team, asking who moved something and detecting the flow to the problem is relatively easy, but what happens when we have a large team? let’s think about one that is divided across the planet, it can happen that not even coincide in time zones and that while one part sleeps, the other is suffering the consequences of error. This is when the tests become relevant since it will be enough to run tests that check the suspicious pieces of code to determine if they continue to fulfill their function or not.
All the above is a perfect example of why a company with a large and complex structure is quite fragile since a small error in the base can throw it away and since the structure is so complex, finding the error becomes a titanic task. The only way to deal with these types of current issues is to build things to last, as I have written before, creating something with the goal that you are prepared for most possible eventualities is a good idea if you want to maintain and improve your structure project.
In the case of software, the tests help us to make our project more robust and therefore less fragile. What tools do you use in your projects (whether related to software or not) to prevent errors that are difficult to detect?
Without any doubt, constantly test what has already been created and in case it shows flaws, fixing them is one of the best practices, but this requires time and effort so it is not always possible to do it continuously or done with the ideal periodicity, I’m sure that there must be other alternatives and it is our duty to find them, check their effectiveness, compare them with what is currently being worked on and if the alternative found is better, implement the changes as soon as possible. Remember, as Jorge Dexler says in his song, Movimiento, “If you want something to die, leave it still”, so if we don’t want our projects to die, all we have to do is not fall asleep, or leave our projects still.
