Pillars & Arcs

Creating a complete program can be something so simple or complicated depending on the reach that the program needs to satisfy. This is an important idea and for us as Software Engineers something we don't need to forget. Usually as how as startups are growing in numbers and in size most of them roll with the same idea. This is that the program should only be able to solve the problems or requirements that were presented. The minimal working product that we can show to clients is the best option for developing new products. Even in the practices for managing the new startup projects are more guided to some type of Agile methodology. This is because it helps to adapt to the ideology that i mentioned before. Developing fast and minimal to the current requirements that the client needs. That is in essence the motto that a lot of companies are guided with. We can see it deviates from the old ideas of cascade methodologies , where usually it was a whole process on determining which would be the requirements for the final product. After everything was perfectly designed and estimated the people would be able to start creating the product of service that the requirements setup for. Moving fast just as the market or requirements move is a good thing, it helps the company to stay on the edge of the competition. Now something curious is happening to a lot of small companies that grew and were staying in the market and are becoming more and more relevant with their software., This is that is becoming obsolete or requires a huge amount of maintenance so it can be efficient with new competitors. Usually this happens with old designs that new versions of the language has a better solution to that problem, or the changes for new requirements needs to change causing patches on the legacy code that is not the best solution. This is why developers even if they are moving fast need to see the bigger picture and make sure that their code is able to accept change. Because if only focus on the current requirements without taking into account how things can change in the future. We could be paying a big price when the problem hits our software.