Microservices

I feel like this article is trying to rationalize / justify something that needs no justification. It felt like it was overly defensive  about the architecture it talks about, when it really didn't need to be in my opinion. Another thing that I feel is important to mention about it (especially in the context of the material covered in previous blog publications) is that from the very start it was clear to me that this article came from a much more recent time than the other ones. Not only because of its mentions of companies such as Amazon and Netflix, or terms like 'cloud' but also because it didn't talk about change in a worried or scared way like the ones that date back to the birth of agile.

Another aspect of this article I'd comment about is that, in general, it gave a vibe and it made it fee like the things it talked about operate at a larger scale. A very large scale.

This leads me to a thing that I've been liking about this course that I hadn't commented on before. It had happened in the past ( in the post about software craftsmanship i think ) that I've felt that the practices mentioned in the content would only work on projects and industry slices that are only beyond a certain size or scale level. I've been both liking and disliking this to be completely honest. I like it because it makes me feel confident that we are going over some for real sruff in the course. I dislike it because in our shallow experience, very few of us have gotten to work and operate in those scales, and it is our perception that a majority of the industry around us is not of that scale.

The 4+1 View Model

Throughout all of the courses that our degree goes over, I believe that we actually go through a significant amount of theory about the UML, with its many methods and diagrams.  (the diagrams are the things that stick with me the most because their visual nature). From what I can remember, we did not actually go over a model (such as the one presented) that would integrated all these different tools. We kind of saw the UML as a toolset, went over every tool in detail, learnt what they did, but never actually covered a method that would bring them all together.

I'll start out by saying that there is a particular thing that I really appreciated about this video explanation: It brings together a bunch of UML tools that I knew about but never looked at in that context. When the presenter argues that certain diagrams or documents (the tools) cover certain 'views' of a project, the presenter helps me make sense of them, it makes them look more obviously useful as a part of a whole, not as isolated tools.

But, what bothers me a bit about the explanation is that I don't actually know if this view model came about to try to make sense of all the different assets offered by the Unified Modeling Language or if it was the other way around. I looked it up and I was happy to find out that the 4+1 view model is generic and does not actually require the use of any particular language or notation. So it was the presenter that was fitting the UML tools into the view model. This is important to me because the view model would have made less sense to me if it existed as a way to fit UML tools into a process. I can rest easy now. Now I'd want to find out if there are other view models for software architecture out there that might make even more sense to me, but that'd be a story for another time.

The SOLID Principles

This one is a hard one for the blog. At the moment I can't begin to produce an opinion about the material that can remotely be 300 words long. I think this was the shortest reading material I've had to blog about ever. Especially in class. Not only that but it was uncomfortably informative. Blogging about it is like being asked to write a 300 word 'comment, opinion or critique' about a random set of five entries in a dictionary.

I guess that from this reading I'd say that I'm getting continually more and more impressed the complexities and details of software making beyond solving complicated abstract algorithm problems. It starts to make sense to me why there's so much worrying for the role of a 'software architect', following best practices, crafting and so on.

These principles (or best practices) particularly are very much focused on situations that arise in very object oriented progamming, which is why I am not ultra familiar to the situations. If looked at in greater detail, I believed that all of the 5 refer to a greater principle we hear a lot about when talking about OOP: the concepts of coupling and cohesion, and how we're supposed to have very little of the first one and a lot of the second one. Particularly coupling.

The SOLID principles addres inter-class dependency, which to me is a form of coupling, of having one class care a little too much about another. Perhaps they don't solve or address coupling directly.  I think it would be more accurate to say that, if followed, they prevent high-coupling situations from happening. Unlike refractorings, principle like this aim at preventing those situations.

At the moment I have a feeling that I have not worked in a project that was big enough for these better practices to be of use, so I am very curious to reach the time (if it ever comes) in which I go like 'Oh! this is it! here and now good software architecture practices are explicitly needed.'

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.