Software design and architecture

I think that for us geeks, the movie War Games is considered some sort of mandatory movie. I had not seen it before, and still knew that despite the sci-fi the movie has, it was entertained and funny. What I loved most about the movie, besides the things it showed about machines at that time, like the sound control they had to access the lines, or how you had to connect to the internet, or the low security implemented back then, like in The cuckoos egg, is that they show the limitations we sometimes tend to forget about machines. They. Don’t. Think. In the movie, after the tech people in charge to turn the key fail the test, they replace them with a super advanced programmed with AI machine, because it would not hesitate to do the job if necessary. This started to cause every sort of trouble when David managed to enter via a backdoor the system had, while trying to filter a video games company. Then, thinking that the programs the computer had were games, David makes the comp

What I liked most about the podcast is the realistic approach that Bob Martin, with all his years of experience, takes on our work context. The tools, the way how we work evolved, how should we do it, how we make it to the professional field, the professional relationship with our customers, etc. I liked how he takes the fact that programmers used to look at cascade developing as a sort of bible or default go to in order to make code and then when we evolved to extreme programming, like the best practices of SCRUM, sometimes abusing some practices like pair programming, ignoring others, like debugging and making mistakes since nothing is set in stone. The truth is that, as “Uncle Bob” says it, we arrive to our first job without knowledge about the real word. The college gives us a general idea, but only practice is what gives us the true knowledge. We are no longer in a controlled environment, you do not know what can go wrong and how to act. In this case, I think that the dynami

It might have to do with the way we were educated by our professors, but I have never thought of software design as something dead or that is dying. The article made a very complete explanation why this is not something true: design is not dying, I agree with the article that design is evolving. As the article states it, going into the extremes of both positions can be something risky, Extreme programming as its prosecutors paint it and with a wrong execution can effectively lead into that glorious spaghetti not understandable code that is difficult to change, to work with and to grow. On the other hand, planning everything and trying to strictly adhere to the original design does not make room for changes that you learn when you are coding that must be made in order to achieve better results and to get to the goal, also if you try to get out a working code as fast as you can, a full old-school planned design is not the best way to go. What the article states, we experienced

I think that the article’s author did a great job for setting a basis for a definition of architecture and for software architecture. I consider that the approach of defining architecture as the part of the design that is considered important, and as something that is difficult to change at later stages of the development. I consider this an accurate approach, since one of the parts we try to define at this stage of our majors is the language we will work on since we are not so versed yet in that field. That being said, this helps to separate between software architecture and the definition of planning and designing of software development. Considering architecture as something more specific than the design helps understand what the past lecture for the blog tried to tell when defining software architecture and its types. On the other hand, I quite disagree with the textual approach they took when specifying who determined what is software architecture. I don’t think that onl