Understanding the SOLID Principles

In the section of the book called "Ace the Programming Interview: 160 Questions and Answers for Success" by Edward Guinness entitled "Understanding the SOLID Principles", the author tells us about the meaning of SOLID. Even though I didn't know this term, I had already heard about the contributions of Robert Martin to the world of good software practices. I could say that a very important assertion was made at the beginning: "the more things you depend on, the greater the chance something will go wrong". In my experience, that is quite true and for that reason, I think that dependencies between classes should be avoided as far as possible.

I think that the first principle called "Single Responsibility Principle" is one of the easiest to understand but at the same time one of the hardest to apply. To get a class to have only one responsibility, there has to be a very good software design, but developers must also devote time to code analysis (especially those that are dedicated to maintenance). Otherwise, programmers will simply do what is faster and simpler: Add code wherever it is going to work (Apparently) what was requested by clients.

The principles with which I do not agree at all are "Open / Closed Principle" and "Liskov Substitution Principle" since I believe that the base classes should have the flexibility to be modified as long as the repercussions of the modification are understood. On the other hand, I think that classes must certainly be made to be extended or replaced by functions, since in this way it is easier to add future changes without having to analyze too much (which is quite useful when delivery times are very limited).

The principle called "Interface Segregation Principle" seems very true to me. I think it is very important to keep the code in small fragments so that they are understandable and reusable at the same time without wasting resources (unnecessary code fragments).

Finally, I believe that "Dependency Inversion Principle" is extremely important for static typing languages since by using this tool, the dependency between the concrete classes is minimized.

Software Craftsmanship

In the podcast called "Software Craftsmanship" with Robert Martin and produced by Software Engineering Radio, many ideas that I found interesting were discussed. It struck me that someone as experienced as "Uncle Bob" (40 years developing) has decided to devote himself to coding rather than being a software designer or architect. Moreover, knowing that he is the founder of a company called "Object Mentor", because the most common is that the owner of a company is responsible for performing administrative tasks. However, it is true that an architect and a programmer should not be separate things, but an architect must also be a good programmer.

The main topic they talk about is "Software Craftmanship" that includes very interesting ideas such as, for example, the improvement of the traditional agile model. I liked the idea of ​​the agile team is the one that decides the artifacts that are necessary and can also be those who produce the architecture document, a task that the architect should traditionally carry out. However, it is true that it can be much more efficient to take the code as the driven document and the documentation to explain the aspects of the code that are not clear.

I think that the relationship that is made between the software industry and the craftmanship is very idealistic but at the same time achievable. Experienced programmers could be considered as master craftsmen who teach to apprentices all their tricks in order to get them to become teachers. If software companies adapt to this principle, they would see a clear increase in productivity and quality.

When talking about the evolution (The step forward) in the agile methodology, they take as a basis the 4 manifestos of the methodology, but with modifications that allow an improvement in this. I believe that the modifications in the manifestos can be summarized in that the software scalable in the future by making it understandable for other work teams.

Finally, I can say that something that made my view wider was the tools that a good craftsman should use. After hearing about that, I will definitely take the time to learn more about my favorite IDEs, about Git, Jira or Bugzilla, about Unit Testing and acceptance testing tools and of course I'm going to learn how to make good tests. I think that anyone who aspires to become a better programmer or software architect should have a good foundation of the tools and concepts mentioned.

WarGames

I found quite entertaining, even for our current time, the movie called "WarGames" directed by John Badham. The film may not have the best special effects, but it does not need them, its plot is simple, but at the same time it is quite suitable. I do not know how important it was or how many people saw this great movie in its time, but I'm sure it should have marked many of the people who saw it. WarGames contains an encouraging message for the benefit of world peace and gives it effectively. I found mpressive, how to integrate the importance of technology with a subject as controversial as World War III. Quite simply, it is concluded that, like the game of tic-tac-toe, if the participants are expert players, there is no way someone can win and therefore it makes no sense to keep trying to win. That same concept is something that the super machine did not understand so the most feasible solution to avoid a nuclear catastrophe was to teach him that sometimes there is no way to win.

I liked that they have put artificial intelligence and technology topics in the movie. Especially, because they were able to transmit simple AI concepts to the general public. In the middle of the 80's, it was possible to show the basis for artificial intelligence in an entertaining way. Through a combination of tests and results analysis, a machine can learn. Although having a fully functional machine replica like in the movie is still fantasy, at the present it is clear to us that a supercomputer like that is very close to reality. Although I doubt that they delegated him as much control as in WarGames, it is quite feasible to make a machine learn almost as effectively as in the movie.

I think that few works can achieve what Badham did with WarGames, transcend a whole generation and continue to like it. Now it is clear to me why positive references are made to the film in the Ready Player One book. I think it really marked the era.