Who Needs an Architect?

The article is about how software architecture can be seen as two different things, one is that the architect understands the general scope of the system, so that he makes the correct big decisions, the other one is that the architect tries to solve all the issues possible.

To me, the first one fits what I think of an architect, I think a software architect should be someone that builds the general idea of the project, divides it into small chunks of important stuff the system has to do. The technology that needs to be used doesn’t matter to the architect at the early stages, the team first needs the requirements of each of the components of the project to decide, based on the requirements what kind of tech or programming language they are going to use. As we can see, that is pretty similar to the first definition the article gives.

Also, the article talks about how the architect could make thing easy to change, so we don’t need to know all the specifics of the project at the very beginning, so we can avoid complexity in the system when we need to make a significant change, but making some things easy to change, the system gets more complex, and if we make everything easy to change, the system gets very complex, so we defeat the purpose of trying to make the system less complex in the first place.

Many authors make the comparison to building architecture, which in many cases makes sense because there are a lot of similarities, but the article makes an excellent point, software architecture is not limited by physics, so, in many cases, software architects have a lot of freedom, but that could be a double edge sword, because it is easier to make a mess.

Fowler, M. (2003) Who needs an architect?. IEEE Software.

Who needs an achitech

The article is about how software architecture can be seen as two different things, one is that the architect understands the general scope of the system, so that he makes the correct big decisions, the other one is that the architect tries to solve all the issues possible.

To me, the first one fits what I think of an architect, I think a software architect should be someone that builds the general idea of the project, divides it into small chunks of important stuff the system has to do. The technology that needs to be used doesn’t matter to the architect at the early stages, the team first needs the requirements of each of the components of the project to decide, based on the requirements what kind of tech or programming language they are going to use. As we can see, that is pretty similar to the first definition the article gives.

Also, the article talks about how the architect could make thing easy to change, so we don’t need to know all the specifics of the project at the very beginning, so we can avoid complexity in the system when we need to make a significant change, but making some things easy to change, the system gets more complex, and if we make everything easy to change, the system gets very complex, so we defeat the purpose of trying to make the system less complex in the first place.

Many authors make the comparison to building architecture, which in many cases makes sense because there are a lot of similarities, but the article makes an excellent point, software architecture is not limited by physics, so, in many cases, software architects have a lot of freedom, but that could be a double edge sword, because it is easier to make a mess.

Fowler, M. (2003) Who needs an architect?. IEEE Software.

Software Architecture

Software architecture is a very important phase on a project, because it can present all the parts or the
necessary things it will need. By having a greater context, not just, single functions, the software
architect could review the “blueprint” in search for errors or requirements not totally satisfied.

At this stage, a change on requirements is not a huge deal, like we saw on software modeling, a
change on requirements will cost more time and money as the project is close to completion.

As Googliffe stated in his book, we need to find a balance between the software’s architecture
being too general, that we can’t understand the scope of the development, or too specific,
that a simple change of requirements will have a big impact on the design.

All software projects need some sort of architecture if they need to be finished on a reasonable
time, even the smaller ones. As the project becomes bigger, it’ll need a bigger architecture,
but it has to still be compact, so everyone, even outsiders of the project, could get a grasp of
what the project is about.

I think the examples given of software architecture comparing it with building architecture is
great because they have same type of success on the project, and a change once the project
has begun, could compromise the reliability of the project and could not be ready for launch on
the due date.

The architecture is about knowing what components of software do, and how they interact with
each other. The implementation and how they work isn’t on the architect’s worries.

Not all software is created equal, so there are many styles to create an architecture. For starters,
we need a good architecture, a project with no architecture most likely will produce more problems
than it solves, “cheap gets expensive”. The most common is the layered, which stacks components
as if they were blocks, one on top of the other, so the top components doesn’t get affected if a lower
component gets changed. The pipe and filter are just components that take data, modify it and pass
it so other components can do the same. The client-server just relies on a external computer(server)
to do the heavy lifting, and then it returns data to the client. Component-Based architecture works
by dividing the project into smaller pieces which talk to each other, all of them solving different
tasks. Finally the Framework is just a collection of predefined methods and functions that a
developer can use to simplify the project and waste less time.

Goodliffe, P. (2006). Code Craft. S. Francisco: No Starch Press.

Moon machines

On Monday, we watched the "Moon Machines: The Navigation Computer" documentary, which is about the Apollo program that the NASA put together to take the man to the moon, and how the MIT used the technology they had at the time to create a computer to guide the spacecraft.

All started because John F. Kennedy gave a challenge to the NASA: landing a man on the moon. NASA put the MIT in charge of the system that guided the rocket to the moon.

As a software engineer, I really appreciated the work of Margaret Hamilton, because we’ve seen the photo of Margaret Hamilton standing next to a pile her size of paper, which contained all the necessary code that the computer needed to reach its goal.

Another interesting part of the video for me, was all the work put into creating a gyroscope, which was fairly big instrument which they tested on an airplane and discover some flaws. This sensor is something we take for granted today because we can find one on the phones in our pockets. Sure, it’s not as precise as the one used to take the man to the moon, but it is amazing the kind of work they did with old technology the had at the time

All calculated data needed to be as close to perfect as possible, because one little flaw on any of the systems, could mean a disaster to the program, so the quality control was extraordinary strict, so many components were rejected.

Today, we’ve seen and heard a lot of people saying the moon landing didn’t really happen, so it's good to have all these engineers talk about their experience on the program because this kind of documentaries help us understand how they actually did it and help clear people's doubts, which are part of why didn’t believe in the first place.

Introduction

Hello everyone! My name is Pablo Alejandro Sánchez Tadeo, I prefer Pablo, but either one is fine. I'm majoring in Computer Science and Software Engineering an the Institute of Technology and Higher Education of Monterrey, currently on the seventh semester.

First I thought this class was some kind of class we would take with Prof. Humberto about the methodology to create great software and how a complete system is created from the ground up, which I think it could have something of the latter, but from the intro class and the fact that we'll use aws, my expectations of the class have changed a bit, so I'm open for surprises!

I'm currently working as a back-end software developer using python and neo4j, which are not the typical tools I've used in the past. I like them because I've never used them so I have to learn new things and expand my vision.

I love cars, how they work and what they can do. Also love driving (when there is no traffic, otherwise I hate it a bit). I could spend hours staring at a good car and knowing about them. It is my second passion after Computer Science. I think it's because I generally like to know how things work.

As for the hobbies, I like to play the guitar, I mainly enjoy hard rock and blues, but I like to listen to several genres, from jazz to electronic music. Also I love food and trying new things, I like trying the typical meals someone would have on every place I go. México has a great gastronomy and I like most of the things people around the country eats.

My favorite trilogy of movies is Back to the Future. I think the concept is well executed. Also love that was made in the 80's and it shows that culture as well as the 50's and what they thought the 2010's would be, which are the decades they travel to in time.
One tv show I like is Stranger Things. that show also shows how living in the 80's was, and it too is science fiction.
Another tv show I watched is sense8 and i liked it because shows life when you share your mind with 7 other people, and how each person has a special skill that could help others solve their problems.