Is design dead?

What I found most important in this article is how it addresses the fact that, today, designing a software architecture has become something extremely complex, but why? Simply the applications that the engineers develop become too complex to know, from the beginning, everything that is going to be needed and the problems that are going to be generated. This is why having an initial architecture, as the project progresses, it is modified too much or left aside due to its futility; however, we cannot begin to program an architecture without having a base, a planning.

This reminds me of when we made our life plan in high school and many people said "Why do we do this? We don't know what will happen in 5 years, everything may change." And of course, everything changed. But having made the life plan allowed us to have a slightly clear picture of where we were going, it allowed us to take small steps towards where we wanted to go and whenever there were doubts we could consult that life plan to find out what was next .

Something similar happens, in my opinion, with the design. It is not something that should be followed to the letter, but it is a kind of guide that you may or may not follow depending on how the project is developed, but if you do not have it there will be no way to go to the place Right.

In my opinion the design is not dead, it has only evolved into a completely different thing. It is designed less and produced more, yes. But this design is more abstract, less specific and allows to be permeable in the development of the project for future changes. It focuses only on the fundamental parts that should not change to meet the system's requirements, but leaves the most specific things such as technologies, service architecture, database, for the consideration of the people who will develop the project, etc.

Who Needs an Architect?

The software architecture has always been known as "the physical design of the software system to be developed" with a great deal of emphasis on the structure of the components and the technology that will be used, at least where I have worked. However, this article mentions some important points that I would like to highlight:

1. It must be understandable for all the people involved in the development of the system, thus becoming the highest level abstraction understandable by the entire work team. This makes it easier for everyone to know where they are digested and make a better work plan.

2. The software architect must be involved with the process and follow up the people involved, serving as a guide for the project.

3. The architecture is based on the most important aspects of the system and this depends on the context, therefore the architecture of a system A can differ greatly in the aspects that it considers with respect to the architecture of a system B.

Finally, the idea of ​​eliminating architecture by reducing the difficulty of changing components at late stages seems interesting to me. Personally I am involved in the agile paragidma of project development, so this idea I think can be implemented not only in software projects but in others that, as mentioned in the same article, are not limited by physical laws but only for imagination, creativity and human capacity. I believe that, although making the systems easier to modify in the future implies an increase in complexity, it allows for better maintenance, selecting the technologies and decisions that best fit the progress of the project and ending with a better final product . That is, to involve the agile paradigm not only in the way in which the project is developed (activities, meetings, changes, etc.) but also in programming (components, classes, methods, etc.).

Software Architecture

All ISCs know the importance of making a good design before starting the development of a system due to the complexity it can have and the increase in the cost of making changes at late stages.

The architecture of a system goes beyond how it is going to be programmed, rather it focuses on the way in which its components are going to be related, to communicate and interact with each other. The importance of this is that programmers need to have a clear understanding of how the system will work because, obviously, they do not develop everything, but they are divided into teams that will be working independent modules that, at some point, must come together to comply with to system functionality.

Personally, it has happened to me that I have had to participate in large systems development projects in which the architecture design is not done and it is a complete headache that, during the whole development stage we have to ask some with others how we need the output or input of some module, how the connection of some modules will be made, if the system can work asynchronously or if the computer (or server in the cloud) we have will be able to handle all the requests that arrive .

Personally, I didn't know the 4 most recognized views of the software architecture, which are: the conceptual, implementation, process and deployment view. However, I think it is quite understandable that, like the architecture of a construction, there are different points of view to better understand the functionality of the system, how the connections will be made and, in general, the way in which the parts of the system will interact, to program them more accurately.

I believe that a good software architect can greatly facilitate the development of a project and significantly reduce rework costs or errors in the system if it is dedicated to making a clear, understandable and available architecture for everyone at all times.

Moon Machines

The Moon Machines video let me see some interesting topics for me, starting with the resilience. I’ve always thought that resilience is the way we achieve success in every project we start, I believe this is truth because it’s almost impossible to complete a project without mistakes, I mean, we are humans and that’s normal. But being able to understand that we are not perfect, and we must start all over again until we finally end up with the correct solution is an important part of being successful.

Another important topic is innovation and collaboration. Since I’ve been studying project management my whole career, I’ve learned that teamwork is very important if we want to achieve success in any project, but also, we need a multidisciplinary team that collaborates with innovative and disruptive ideas. The more diverse the team is, the more innovative ideas we can generate. But further than that, being cooperative with others is important as a personal skill.

The fact that they were programming all the information to bring the Apollo to the moon with so low computing power surprises me. All those ideas the engineer came up with are impressive to me because of the complexity of knowing how to lead the rocket in the right direction taking in count there’s no gravity, coordinates or references.

Finally, I always thought that bringing the man to the moon was a great achievement for humanity because of the complexity and uncertainty, but after watching this video about the effort, ideas, failures and successes now I understand better that it wasn’t only an achievement for humanity but a demonstration of perseverance, union and a shared vision. Humanity proved that we only need one shared vision to collaborate with others despite our differences in favor of development and human growth.

Introducing myself

Hello!
My name's Ethan Bautista. I'm 22 years old and I study Computing Systems Engineering.
I like to read books, listen to music, play videogames and hang out with my friends. My favorite color is purple and my favorite movie is Little Manhattan.
I'm currently reading Game of Thrones which I really enjoy and I'm also planning to read the 2nd book of "The Queen of Hearts" because I liked the first one so much.
From this course I expect to understand how to design and deploy software architecture for solutions in IT environment such as Artificial Intelligence or Education, which are my preferred areas of knowledge.