Software Design and Architecture

Well, finally a sensible article into the mix. This article complains about the woes of software arechitecture. To this day, it seems that software architect is a title added to a developer who complained about not getting enough credit for their work. But there seems to be a high level view of a project achievable at a certain point. The person who has the overall view to see and understand how the puzzle works together.

I love the derogatory definition that is given on the article:

Architectus [..] is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow. [1]

Not quite, what is interesting is the next definition.

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms—such as development costs. [1]

Well, there you go. One of the most interesting things I learned, is when I got my forensics class. I got to listen to an expert of digital forensics. One of the most memorable times I got excited, is when he did accurate metaphors, of how technology works.

[1] “Who Needs an Architect?” (PDF) by Martin Fowler, published in IEEE Software, July, 2003. 

The article starts with a metaphor where the author compares software design to complex cities. At the start of the chapter he mentions that the way we design software correlates strongly to the way architects design buildings. This first part I'd like to juxtapose with the idea that requirements don't exist as the way we know them. We can't know exactly how a software system is designed due to the constant changes of the stakeholders, and the fact that we might know that we want a house, but we might as well don't know what we want in our CRM.

He even mentions it in the book "You don’t start with all of these. Particular views arise as development work progresses. The main result of the initial architectural phase is the conceptual view, and that’s what we’re concentrating on here."[1] We have to have a conceptual view of the "building" we are trying to design.

If someone sees a blueprint, they have a good idea of what to expect in a building. Can we do something like that for software design? For me the best way to express it is having a video with some screens explaining the process. Even though they might be hand drawn, we can expect to get to a basic level of understanding. HELL even just sketching it in a UX designer and making it simple.

Enough Said.

Let's start doing our code like that, compliant with modern standards, while thinking in the high level design of it.

I love the examples Pete Goodliffe gives of how different types of designs are equivalent to different types of pasta. Having lasagna and other frameworks as canned goods, certainly drives his point home, and makes this a wonderful read, including his triffle cake, that to those who don't know what a triffle cake is, go google that delicacy.

[1] “Software Architecture: Laying the Foundations of Software Design” form Pete Goodliffe’s book “Code Craft: The Practice of Writing Excellent Code.”.

As tradition follows, we usually get screenings of interesting movies in class, today we got a screening of Moon Machines [1] a documentary by the science channel about the Apollo Guidance system and their corresponding code.This documentary was about the testimonies of people in MIT and the general creation of the whole Apollo mission.

What is interesting is that some years ago, I saw a GitHub repository of the commentated Apollo  code, It is wonderful to see such a marvelous display of engineering be on a repository in the internet. I invite you to also read the issues on the repository.

I'll add some excerpts here that I found interesting, but what is more interesting yet, is that there is a compiler in the internet for this code, you can head over to the VirtualAGC GitHub and compile your own Apollo 11 and simulate a lunar landing. If you want to spare yourself the hassle of learning everything about Apollo's computer, check out this YouTube video which does everything the astronauts did to get to the moon. 

What is most impressive for me is the way this guys thought about software in a very specific fault-proof way. Today we have compilers which foolproof our ability to do faulty code.  Is it real that we are inside the time that software quality is at its all time low? I don't have the answer for that question, but what I can say is that this code is árt, even though we aren't able to read it easily (more because it is just subroutines directly) we can see that for this guys to do something never done before, with this precision, takes a huge amount of determination, perseverance, and  intelligence.

# LOAD VERBS IF ALARM CONDITION IS DETECTED DURING EXECUTE,

# CHECK FAIL LIGHT IS TURNED ON AND ENDOFJOB.  IF ALARM CONDITION IS

# DETECTED DURING ENTER OF DATA, CHECK FAIL IS TURNED ON AND IT RECYCLES

# TO EXECUTE OF ORIGINAL LOAD VERB.  RECYCLE CAUSED BY 1) DECIMAL MACHINE

# CADR 2) MIXTURE OF OCTAL/DECIMAL DATA 3) OCTAL DATA INTO DECIMAL

# ONLY NOUN 4) DEC DATA INTO OCT ONLY NOUN 5) DATA TOO LARGE FOR SCALE

# 6) FEWER THAN 3 DATA WORDS LOADED FOR HRS, MIN, SEC NOUN.8  (2)-(6) ALARM

# AND RECYCLE OCCUR AT FINAL ENTER OF SET. (1) ALARM AND RECYCLE OCCUR AT

# ENTER OF CADR.

    “Moon Machines: The Navigation Computer” produced by the Science Channel. This video was seen during class on Tuesday, January 9 [1]

Well, this is it boys, time to go for another semester of awesomeness.

This time around, we are going to have our Software Design and Architecture class. This is an awesome opportunity to enjoy the different design patterns we can learn about. I've always wanted to learn software patterns which are not clear to the average coder. I'm excited that this class is one of those things that most people don't work a lot in, which is taking empirical knowledge out of books that have experienced difficult scenarios themselves. 

If you go and try to learn a new programming language, you'll get to know whatever you need to solve your problem. If you study a book to learn the language, you'll get to learn the language fundamentals, but not the gems of the language which are the difficulties faced by previous engineers. 

Weirdly enough, to the detractors of college, it seems that sometimes its value is overshadowed by the tuition of the corresponding course. But I disagree with them, the best part about college is having 6 months to focus on a specific part of the software engineering world.

· Your hobbies and personal interests.

I love playing video games, specifically Rocket League, but I also exercise almost daily, and I try to read at least 30 minutes a day. Lately I am very interested in psychology, so I am reading and studying a lot of this.

  Books, music, movies, TV shows, etc. Which you have recently enjoyed.

Books you've enjoyed a lot lately: Influence by Robert B. Ciadini. Rework, by Jason Fried. Think Like a Freak, by Freakonomics, and Paul Allen's Idea Man. Also, the series that I liked the most is Black Mirror.