Designing Success

The article given for this week, while highly concise and technical, provides an outlook for quality in Object-Oriented design and programming. While some might argue that there is no universal principle for quality in software and every case and system must be carefully considered in order to balance everything out, I think there are some general ideas or heuristics that we can adhere to in order to aim for quality even in doubt or if we don’t have a true idea of our system. I was also surprised to discover that the software world can be very small, as these set of ideas were proposed by “Uncle Bob”, writer and/or participant in various other articles of which this blog is thankful for. According to my experience, when I learned about OOP, even without a class or lecture dedicated to these concepts, one seems to tend towards these practices. What I mean by this is that carefully using all the capabilities and features of languages such as Java or C#, certain patterns such

It has been a long time since I have seen a movie from the 80’s. I had forgotten how corny they can be, not that it is a bad thing, and it is just that they are not as common as they used to be. I really liked the film; it made me laugh with all the ridiculous situations and all the liberties it takes when David hacks into stuff and gets out of situations at the nick of time. For the most part, it showcases what was a very serious topic (the Cold War) as a parody of itself, with chubby militarymen, threats about launching nukes at the slightest provocation and a paranoid government that would even suspect a 16 year old of Soviet espionage just because he has low grades but he is smart. There are, however, some plot points that I just could not get out of my head while watching the movie. First of all, I do not think that Joshua’s nature when David plays a game with him is justified or fully explained. At the beginning, one of the main WOPR engineers tells the spokesperson from

I think this has been one of the most dense and varied source content for one of the blog entries for this course. I guessed at first that the podcast would concentrate on topics mainly revolving around techniques and tools that make a programmer a craftsman and how one can benefit from said practices. Bob Martin seems like a very passionate person who understands, or at least tries to, what are the causes and situations that result in the current state on the industry. He also loves to code and believes that everything that we produce must be a reflection of said code. In general, I have been convinced by him and I really liked all his anecdotes and general knowledge of computer and programming history. He really does come off as an eccentric uncle. His point about architects and how young people tend to aspire or have management roles as a goal, rather than just aspiring to be really good programmers is kind of a mixed bag, at least for me. Normally, when one person is in cha

The article written by Martin Fowler proposes a number of interesting techniques that seem to be the result of working and suffering a little with several kinds of design patterns (or lack thereof).   He shows that he has a lot of experience working with several teams and different types of projects, enough that he has been able to experiment and create his own way or method for designing. This method tries to takes the best practices from both evolutionary and up-front design, claiming that they both have advantages as well as pitfalls. However, his writing may suggest that he likes XP (good evolutionary) a little bit better, since he only mentions a couple of problems with the agile practices, most of them related to the people who practice them badly or take them too seriously. I completely agree with the part about people and how their disposition or will can make a project be successful or a complete mess. Last semester, I was in a special project for the school that requi

Architecture can be a hard word to define, especially for a student who has had close to zero experience working with industrial or real life projects. While the article works hard to try and describe it based on the experience of several people. Each one has his/her own opinion and “guesses” the answer based on they think is important (or not) about this mysterious part of software creation. In this post, I will try to do the same from a unique and rather ignorant point of view. Up until the last semester, I had never really been concerned with decisions concerning the grand scheme of projects, whether because all of the work that I had been working on has been relatively simple (less than 3,000 lines of total code) or because said projects never needed to be seen by the perspective of someone like an architect or devops engineer. I just needed to make sure the program met the requirements of the class I was in and that was it. Going by that kind of experience, all I knew abou