Posts

Microservices

I want to start with a popular phrase that’s being quoted in the article: “ not every problem is a nail and not every solution a hammer ”. The reason to start with it is because when people know something, we tend to find a solution that fits into something we know or recently learned. So, quoting Martin Fowler on a later article 1 he wrote in 2015: “ So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith .” Also, Fowler says on that same article 1 “ is a microservice architecture a good choice for the system you're working on? It depends… ” Throughout the original article, Fowler mentions the cases that would be the appropriate to adopt the microservices model. For many years, a lot of systems were developed and envisioned as monolithic structures that were hard to deploy, especially in large enterprise systems, that often had the problem of intertwined code, that when modified

Software Craftsmanship

As the definition for craftsman says it is “ a person who is skilled in a particular craft ”. People tend to think of other professions when someone mentions craftmanship, maybe an artisan, but very rarely they think about a software programmer. So, it’s fair to say that writing code is a very particular craft that needs highly skilled people. You also need a particular training and a particular set of tools to do it. But even in writing code, there are certain levels of quality, which make the real difference between well-made software and crappy software. As Bob Martin said on the podcast, back in 2009, lots of systems are in a state of disrepair, and in my opinion, lots of the current systems within companies and organizations are in the same state. Some systems were developed years ago, modified through the years making it harder and harder to maintain. It’s true that sometimes programmers don´t even want to change a module because the system can fail,

Hidden Figures

Back in 1961, when the USSR and the United States were in the middle of the Cold War, the Space Race was a competition (if you want to call it that) to achieve firsts in spaceflight capabilities. Both nations were trying to send rockets into space, to put satellites, people in orbit around the earth and even with the objective to put men in the moon. NASA was created 3 years before in 1958 and both countries needed the best minds available to do groundbreaking work that had never been done before. Some states in the US still segregated black people in schools, work, health services, libraries, bathrooms, transportation, among others. So, what were the odds that 3 black women would be fundamental in the development of the Space Race at NASA? Actually, pretty low, but that didn’t stop Katherine Johnson, Dorothy Vaughn and Mary Jackson, who worked at the colored computer division at NASA, making calculations for the Space Program. Hidden Figures is the movie, based on the story of

Is Design Dead?

In this long article by Martin Fowler, he talks about software design and its applicability. This article was written in 2000, with its final revision on 2004. Still, the concepts he talks about are still applicable up until this day. He talks about the main styles of software design, which are planned and evolutionary. As he states, the main problem with planned design is that is really difficult to foresee the changing requirements of a system as it keeps growing and evolving. So that can become a problem, as sometimes the issues that come up can become more difficult to handle on the original design approach. On evolutionary design, the design keeps changing as the project is developing and becomes part of the programming processes. The issue is that it becomes messy and hard to track down the in the long term, making the code harder to maintain and more prone to bugs. When Fowler talks about how design applies to Extreme Programming (XP), he also sa

Who needs an architect?

It’s hard to have people agree on any subject, and this could be talking about politics, religion but also software design. Even in the software community people can’t agree the definition of a software architect, let alone if they are actually necessary or useful for a project. In this article by Martin Fowler, he talks about this, he actually tries to define both, the concept of architecture and also the software architect. He defines software architecture as a shared understanding the expert developers working on a project of the system design. So, this means that the architecture of a system depends on the vision and involvement of the developers, to fully understand how a system should work. But it’s also telling us that it needs consensual agreement by the group, which sometimes can be hard to reach, especially when the system become too large or too complex. But as the author also says, everything depends on what the developers thinks is importan

Software Architecture

In this chapter we took a look at the concept of software architecture. As it says, we are comparing the ancient activity of constructing buildings with bricks, to the more recently created activity of building software and systems. And we think of software as the combination of several components that will create a bigger system, just as we have done with bricks, cement and other materials to create a bigger building and not just a collection of walls, roofs and doors. While making a building, we can create our own vision. The same thing applies to software creation, each programmer has a different vision. The real issue comes when people that haven’t been involved with the creation of the software comes along and tries to understand the system. If the system has a well-defined architecture and clear components, it will be easier for new developers to modify and create new components. On the contrary, if the architecture is messy, then it can become a real

Moon Machines

Image
When you have a task to do and you don’t know where to start, you might feel a bit lost. This is basically what happened to the team that had to build the rockets, that would send mankind to the moon. The quest was one of the most challenging ever and NASA had to find the way to distribute each task to the best available for each job. It had to involve not only mechanical engineers to build rockets, but also mathematicians, physicians and of course computer engineers. In my opinion, one of the most relevant things that the documentary shows us is teamwork, because everyone knows exactly what they are supposed to do to achieve the common goal. For example, the team that had to squeeze the size of the computer knew that was the only way that a computer could fit into the lunar module. But doing their part of the job was also critical for the success of the Apollo program. In teamwork, all people must have in mind the common goal. Even if their participati