Understanding the SOLID principles

Last week we listened to a podcast where Bob Martin was interviewed about software craftsmanship and techniques to make coding better. He also developed 5 principles he recommends to enhance object oriented programming, which are the following:

• Single Responsibility Principle: This is that the class we are working with, needs to be useful for one thing and one thing only. In a previous text, we learned that we could use compositions to avoid making several things on one class. The theory is easier to grasp than the practice. In practice, you must rely on experience and common sense. Not following this practice may end up in a developer really frustrated trying to understand what the class is doing.
• Open/Closed Principle: Any class should be open for extension but closed for modification. For that we probably need the skills Bob mentions on the past article, so we gain experience with making code difficult to break, and at the same time, be accessible, easy to understand and introduce new functions and features. The principle means that when adding new behavior you should leave base classes alone and instead create new, inheriting classes
• Liskov Substitution Principle: This principle is in charge of  keeping the happy working relationship between classes and functions alive and well, when one class inherits from other. Experience tells us that changing the behavior of a class in many cases leads to problems elsewhere in a code base. It is another example of how you should strive to minimize dependencies of all kinds in the interest of writing robust and maintainable software.
• Interface Segregation Principle: Avoid writing huge interfaces that give classes a lot responsibilities they don’t need or want. The developer needs to have the ability to instead create a collection of smaller, discrete interfaces, partitioning interface members according to what they concern.
• Dependency Inversion Principle: This principle means is that instead of writing code that refers to actual classes, the developer should instead write code that refers to interfaces or perhaps abstract classes.

Software Craftsmanship

Bob Martin gave an interview about craftsmanship software and agile software techniques, which are directly correlated, because craftsmanship tries to up the developers skills and the agile software techniques are the ways a developer could improve them. Bob also thinks that they have a lot in common.

Bob talks about how we, as developers, get the craftsmanship of the software when we are in our jobs, in some sort of trial and error manner, this happens as we are building our skillset so we can build better code faster, but Bob thinks the developers need to learn this things on school, so instead of trial and error, it could be more like an educated guess. I’ve learned a lot of nontechnical things on my jobs, things that may take too much time to put them on a course, also, seen those things in practice helps clarifying a lot of things a developer may not understand with the theory.

We also try to develop our agile software techniques so we can solve our coding problems faster. Companies learn from their and others mistakes, so they create standards to ensure the employees get the right focus on the right skills, so they get small things done very quickly, making easier the error detection. This agile techniques, allow developers to get things done in less time and focus on bigger problems.

Not all college developers have a good craftsmanship, because not all have the opportunity to get a job o just don’t want or have the time, but this skills are necessary for the developer to get their work environment ready in no time when they get their first job, that’s the reason students need to get that experience from bigger college projects or projects that are not necessarily part of any course.

War games

War games is an 80s movie that talks about a machine that could simulate several war scenarios depending on the current conditions of each county involved in that specific war. This machine was created because there was a test for soldiers if they would be able to turn a key to activate a nuclear bomb to kill dozens of people. Turned out, soldiers weren't able to turn the key because they thought of all the people that bomb would kill, so this machine was built because doesn't really care how many people die if it needs to throw a bomb.

In the other hand, there is a geek guy called David Lightman that isn’t really interested in school, but he is really good at computers. So he change his and a friends grade so they pass the course. The movie were filmed in the 80s, so the internet was very different, he had to connect through dial up, so he put his computer to dial all numbers in the area of a videogame company so that he could get info on a game that isn’t out yet, he found what he thought was the company's files of its games, but then he looked that there were games with strange names like “global thermonuclear war”. That game ends up being the machine the government created to simulate the wars. The machine was created by Stephen Malken, who was an AI researcher when the machine was built, so it could learn more as the simulations were finished.

David started playing with the machine as the Soviet Union not knowing that he really started a simulation that would trick the military into thinking they were under attack. They tracked David down and explain to him what he has done.

The machine can’t really tell that the US is under attack, so he tries to launch lots of missiles. David tried to convince Stephen to help him stop the machine. He realized that the machine won’t stop playing even it has no chance of winning, so he put the machine to play tic tac toe so that the machine learns that there could be no winners, so it applies that new concept to the war simulator and discovers that, in some cases, the only way of winning is not to play, so the missiles were not launched.

Is Design Dead?

Is Design Dead?
The article talks about how the design has evolved over the years, and developed good practices to create a good design with ease.

Like in other areas, we, as developers, have tried to develop a way to create good design. Many other areas already have good standards on how to create a good and effective design, but in computer science, we’ve still not refined the methodology just yet. But we’ve discover some things that make a good design, for example, our code has to be somewhat modular, it has to be easy to alter, because the system probably won’t stay the same for the rest of the days, it’ll probably need maintenance, so a good design, should allow easy maintenance and the new features should be easy to incorporate. It is harder to modify a design in the middle of the development, even if the changes are good, because things need change to adapt the new design and there could be more bugs at the end.

Design should be done before development. Designing the software while it’s being built could end on a project with no Quality Assurance, it could take longer to develop and most likely have a lot of bugs. The software designers first create the design of the entire project, so they can get all the informations and sort the bigger problems, so they are not distracted by the technology programmers use. Then programmers follow the design so they don’t have to worry about other stuff.

Software should be simple, the team has to be focused on what is important now and build only the features needed, they don’t need to waste any time and resources building features that could be used in the future. This is, creating the least amount of code possible. Reusable code should be used properly, so that there is no duplicate functionality.