GLOBAL THERMONUCLEAR WAR (War Games)

Ever since I read through the part of Ready Player One where the movie 'War Games' appears I've been thinking that we should watch it in class one day instead of the other media that we usually do watch (Silicon Valley). I even mentioned it to some of my classmates out loud. I know that watching it was probably planned in the course all along (I believ that it's in the nature of our professor to have things planned like that all along) but a tiny part of me still likes to believe that he overheard me saying it in class and thought 'you know what? yeah we should watch War Games one of these days' and so he mercifully got it and played it for us.

Anyway, I really enjoyed the movie. Even though our professor warned us that the movie was old and that it showed a lot I don't quite believe it did. Not enough for that warning. Where it did, it didn't bother me at all. I think that when a movie is good like that my brain just accepts the universe it presents to me without questioning it. Another influential factor is (I think) that our professor was there in the setting that the movie presents, and I think he can remember and/or relate to the things in the movie, looking back. He sees and has lived the aging with the movie (Gracefully).

One of the things that I enjoyed the most about the movie is that despite having been around for a long time it actually kind of touched upon the single thing that actually worries me about computer security nowadays: with so so many super important, mission-critical or classified or life dependant information and procesess being hosted or automated with computers and the internet, I sometimes consider the possibility of two or more powerful groups (not nations necessarily) getting into conflict or crysis because of something that happended in the computer-data or internet social media world. Just like the characters in the movie, it's a scenario that I wouldn't like to live through.

Software Craftsmanship

I liked this episode of SWE Radio. Uncle Bob Martin is an interesting guy to listen to, and I think that the host of the show makes a good job as an interviewer, extracting the fundamental opinions that Bob has on a lot of issues. Martin esentially presents a very interesting take on the process of creating software. He says we should craft software.

Martin presents and defends.. what I guess you would call a movement called Software Craftsmanship (I know, it's kind of bad that the name tries to appeal to a relatively young industry and yet it excludes an entire gender). He explains that basically, ever since agile came about, the software industry lost an important focus on software quality. That it is overly concerned with agile processes and meeting business goals. He believes this is wrong, in the sense that the situation is contradictory: software quality helps meet business goals in the long term.

To solve this issue, he says, the software industry should be composed mainly of software 'craftspeople' (he actually says 'craftsmen' /: ). A community of professionals, something that sounds like a guild (he references the law industry and the medical industry), that craft products and should be proud of how they do it.

Even though I think that this is a good idea, I also believe that our software industry is so so varied that it would be hard for everyone involved to follow this movement closely. Especially for the industry at the smaller and smallest scales, this whole movement gives me a feeling that the discipline and effort involved are just too much work for the scale. Just like with doctors or lawyers or even carmakers, I can see this working very well at higher levels, at bigger scales (In fact, in my experience, a culture like this is expected from a programmer at the largest scales). It sounds like a top-down solution that leaves out the bottom tiers. Maybe I'd like to hear about something that is more bottom-up.

Is Design Dead?

These past articles have left me with a strange feeling of.. something that is similar to boredom. Not in a bad or offensive sense, just something... aniclimactic. I end up feeling like these people are too surprised, or overly excited, or worried about the things they are talking about. It is a strange thing to experience. But this was the article that finally allowed me to understand why I was having those feelings. I looked at the dates. I finally laid my eyes on the dates when these materials were written. 
This piece of writing in particular (Is design dead?) was written for a conference that was held in the year 2000. That was nearly two decades ago (damn we are old!).  So now I understand that when these people talk abou this as if it was just discovered the day before or as if it was beamed down from an alien spaceship is because it was! (not the alien part). 

These authors were just learning and gathering experience with new ways of doing the things that they had been doing (probably) for years. They were indeed concerned with what it all meant and how the future was going to be for the industry they knew.

Today, even as rookies, most of us are familiar with iteration and evolution. We came about when these ideas were already out there and being used to produce software at the largest of scales. When Fowler says "no, design is not dead" it is obvious to me now, when I'm conscious that even when you build projects in iterations and evolutions you are always making little design choices, always desigining, even if at the tiniest of levels. But now I understand why it wasn't obvious to him. Why it wasn't obvious to them. Back then.

Who needs an architect?

It seems to me that this dude (Martin Fowler) was (at least at the time of writing this piece) as confused as I am about sofrware architecture. He is inconclusive (to say the least) about software architecture itself. He does make some subtle and interesting points (most of which I agree with) about the process, art or act of making software but I really disliked how he had to ramble on and on about the search for the 'true definition' of software architecture when it appears to me that his article is not about that perse. I'd be grateful if he could just state his points plainly and just make his thought-train-discovery process and discussions (the rambling about the definition of architecture) available to the reader if he/she desires it. I'm not reading his stuff for entertainment.

His entire article could be summarized in the following: "There is no one definition of 'software architecture' because it is a very subjective concept because building software is not limited or bounded by anything physical, but only by the minds and intelligence of the people doing it." I agree with that. I didn't need the rest.

In my eye design has a very simple definition: You are going to produce an object. A thing. That thing has to meet/have a very peculiar set of goals and requirements. If you create your object in such a way that does, you've made a good design. Otherwise, you haven't.

That is my personal definition, the one that I go with in my life. It is very general. Anything beyond that would be a bit too specific for me to try to apply it generally like I do with the one I mentoned. This is why the authors piece on the search for a specific and yet generally appliable definition of what he calls 'architecture' is very unenjoyable to me.

Software Architecture

This was an interesting read to me because it managed to convey the ideas and the intuition behind the thing that it was explaining (software architecture) without saying a single word about how anyone is supposed to actually go and create ‘a software architecture’. It kind of makes sense, since the thing it is talking about is very abstract itself. “It should do this, and do that without too much of this, and with just the right amount of that, but always taking that into consideration.” But not a word on ‘you might want to use these diagrams’ or ‘use a text file’, ‘a mailing list’. Just ‘a document’.

What I understood from that is that the document defining software architecture can be a lot of things, because you can do software architecture in a lot of different levels. At the beginning that didn’t quite ‘click’ with me.

But if there’s a position from this reading that I can agree with is this: from a programmer's perspective, knowing about and having your design (or ‘architecture’) in hand is like a guiding light. Like a scuba diver’s lifeline, or the mission objectives in a video game. It keeps you on track. When you take on a project, defining that higher-level ‘solution’ is a problem that you should only solve once, and the solution you produce must be one you can adjust later but most importantly, it must be one you can trust later. Because later you’ll be concentrated solving the fun lower-level implementation details and you don’t want to be questioning why you were doing all this to begin with. No one has time for that, you already went through it. Having that clear ‘architecture’ in mind allows you to go ‘oh, this is why things are this way, this is what that is supposed to do, this is how I’ll make it happen’.

In my experience, I’ve received this guidance from lots of different places: from a well-defined project folder structure (that is initially empty), to an ugly-looking drawing-diagram that conveys just the key points of what the thing I’m working on has to do. This is why I think it makes sense for the author not to talk about the object representing the architecture as anything other than ‘document’.

Moon Machines: Navigation Computer

I believe that the Moon Machines: Navigation Computer documentary presents a good example, a good argument of why careful design is important in almost every piece of technology one sets out to make.

In my opinion, the documentary presents the story of the computer (and computer software) that guided the navigatio of the first Apollo mission to go around the moon and back. It mainly presents such story through the experiences of the 'programmers' and engineers behind that project. People who were (at the time) young students from MIT.

These people tell stories of something that ended up being a software project, but at a peculiar time in which software was a very new thing. As such, it is evident that the study of it's contruction and the processes behind it were not a thing yet. It is in those personal stories by the developers in which the argument for the need of a study of software making study becomes evident. The tales of the developers and of the unfolding of the project are stories of hardship, of problems that software projects of today sometimes suffer too.

With the knowledge we have today it was easy to look at the problems they mention: being behind schedule, and having the role project demoted because of it's lack of readyness, as a consequence of the lack of experience and planning that they had. But it is also not hard to relate to the frustrations they underwent as precursors to these problems: not eve knowing or planning what they were supposed to do, having no clear goal or requirement in mind at the beginning and poor organization between the teams of software and hardware.

I think that those people, thosw first developers, are  to thank for the knowledge that today, to a certain extent, shields us from falling into doing the same. For the knowledge that software is just another piece of technology product of engineering, and that like any other engineering project, ends up being better if coming from processes of design, planning and careful thinking.

Intro

Hi there!
Welcome to my blog for the software design and architecture class!
I'm Gerardo, most people call me Gerry. I'm the 8th semester of the ISC program and I have the 'regular' schedule according to the program.

At the moment I do not have any particular expectations from the course other than to go through a large amount of good practices to follow when constructing larger software projects. I believe that most of them will make sense and will actually be helpful and of guidance when the time comes for us to actually work on such projects. (Hopefully, and maybe, just maybe, we'll get to play around with legos again).

 I'm generally interested in computers, programming, and what computers can be made to do for us as a species through programming. I like knowledge. Other interests of mine include videogames such as the Halo saga and Super Smash Brothers. Generally I spend time learning random stuff on the internet and watching anime and/or going out with my partner.

Recently I re-watched Netflix's Devilman crybaby and I enjoyed it just as much as the first time, it only reaffirmed my opinion that it is am true masterpiece and a modern classic. During the winter break I also watched 'Rascal does not dream of bunnygirl senpai' and Trigger's 'SSSS.Gridman'. I enjoyed both very much, although I'd take the latter one if I had to pick. When there's nothing to watch I just binge the infinite Rick and Morty stream while I do other stuff.

At the beginning of the winter break I challenged myself to read Cormen's Introduction to Algorithms. It's been tough. I'm also reading 'A Tour Of C++' by the dude who made C++ himself. I figured I should know the language before I graduate.

Music-wise I've been listening to lots of 'electro'(?) in my search for music similar to Porter Robinson's 'Worlds', with artists such as k?d, Robotaki and Illenium. I've also been listening to local jazz by 'Alex Mercado Trío'.