Entradas

The blind programmers

I liked a lot the two videos and the reading of this week, all aimed to teach the lesson that there are some things that are really big for one to understand alone. Perspectives are the most important part of dealing with a  complex problem. The worst thing one can do is to think that their perspective is the only one that exists. This is specially true for systems architecture, according to the video of the 4 + 1 views any complex architecture instead of seeing it as a whole. Each view represents one important part of the whole system and it is easier to explain than to explain it as a whole. The 4 main views are: Logical: Structure and functionality. UML: Class, Communication, Sequence. Process: Process and communication between them (dynamic). UML: Activity. Development: Management of software artifacts. UML: Packages, Components. Physical:  Topology of the physical part. UML: Deployment. There is an extra view, the most important one in my opinion. Use Case: System as

SOLID

This week's reading was basically to understand the SOLID principles. Which are: S ingle Responsibility: A class or method should only do one thing and one thing only. O pen/Closed: Once a base class is done there shouldn't be any modification at all, only extension. L iskov Substitution: You should be able to change a base class for one of its child at any given point when referencing it. I nterface Segregation:  Have several small interfaces instead of one big interface. D ependency Inversion: Instead of using concrete classes use interfaces inside classes to avoid depending on a concrete class. These principles were presented first by Uncle Bob but the name was coined by Michael Feathers. The main theme of this principles is to avoid dependency while programming, to make the code complexity as simple as possible.

Is our future Microservices?

Microservice architecture is a handful approach for cloud development, basically it eliminates the idea of having a monolithic architecture and instead having small components that communicate themselves through simple protocols. The truth is that micro services are very good for implementations that require to be constantly updated but not as a whole. It also helps to protect data by decentralizing it. As such the problem is that businesses are abusing of this services idea and create a lot of unnecessary services in my experience, although the concept is very appealing if the problem can be easily solved with a monolithic architecture, it should. One should not create services just for the sake of the mode, one should create them because it is easier to work with them, not incredible difficult to maintain.

We should all be Craftsmen

In the episode 150 of Software Engineering Radio Bob Martin teaches us about Software Craftsmanship. Which is an extended version of a Software Architect for Agile development. According to him, Software Craftsmanship focuses on the skills fo each developers, architects should also be coders in this sense.  Craftsmanship as its name indicates is an approach that instead of focusing on budget focuses on quality. According to him, the prioritization of financial concerns in the software industry is the main illness of it. A good craftsman takes time in knowing the IDE that he/she is going to use, also he/she uses version control such as git or mercurial in the project. Makes unit testing and bug tracking.  According to him,  Agile Developers must adapt to change, but Software Craftsmen every time they make a change must add value, either in features, defect repair or efficiency. The Boy Scout principle is to leave the place cleaner than what you find it, and this applies to code as wh

Hidden Figures - Movie

I had seen the movie before class, and I have always liked it, because it shows how powerful persistence can be. Also, I thought it was great for the class with the think different approach of maybe not inventing something new but reusing something old for new purposes. When they were thinking on how to pass from elliptical to parabolic orbit, they were overthinking on how to create the new math to make that operation possible, when the solution was to use an ancient method. I also thought it was a good movie for the month, a movie to commemorate the fight for women's rights. I found really disappointing the way things were not so long ago, there was not only differentiation between men and women but between "colored" and "white". This can be seen in the movie in many parts, but the best example is when the two ladies are in the bathroom and the supervisor says "I have nothing against you" and Vaughan says "I know you probably think so" beca

Design is dead and we have killed it

The reading was very interesting, talking about design in XP practice is somehow difficult. I completely agree with the author in the sense that there cannot be good software without design. But from what I read, there is a lot of crapy practices in XP. It was interesting reading how XP enables evolutionary design to work by using simple design, and I think it is a good solution to develop quickly, but the problem is that XP should only be used in these cases. XP is not a method to develop a big system, because big systems require a lot of design, it is true that the YAGNI rule applies in a lot of ways to keep entropy down, but sometimes you need to have a clear and simple design that will work with the future upgrades to the system, at least in my experience if the technology is not chosen adequately it can cause a lot of damage to the system and it is during the design face where we choose a specific technology and then stick with it. It is in this case were we need to think of futu

Pretentiousness in the word

I found really interesting how the reading starts by destroying the pretentiousness in the definition of architect, indeed, I have always found myself disgust by the title. I have worked with many architects in my life, some Reloadus and some Oryzus, whenever you are dealing with an Oryzus architect they do not like to be called architects, they are the leaders of the project and try to involve everyone in the design decisions. The architect Reloadus, instead, believes that his/her title gives him/her some kind of nobility and that they become powerful and untouchable, in my experience, this kind of leader can be left out of the equation and the system can still be very good. When the reading says “We shouldn’t interview anyone who has ‘architect’ on his resume.”  I think he meant that a real architect is humble and would not call himself/herself an architect, at least not in a pretentious way. For the question, who needs an Architect? I believe that every development project needs a