And then there was one…

This will be my final blog for this course, and all I can say is that I had a blast making these blogs. At my university, courses are usually very linear, and that can be tedious sometimes. You follow a certain path until you reach a goal, and you either pass or fail. In this course, things changed, and I really enjoyed that professor Bauer made us create this blog. Internet presence is a huge asset today, and I’m glad that I have some very good material on a bunch of software related topics, be sure to check them out!

All of that text above this is not really correlated to the topic, so sorry about that! Alright, today’s topic will be about the relationship between Agile development and Object-Oriented programming. Both are topics that I’ve covered before. Both have pros and cons. And both of them are very important to the industry and serve as a backbone to many systems and projects alike. So, are they somehow similar? Are these two movements correlated at all?

The answer of course, is yes!

First there was Object-Oriented programming, which started way back around the 60’s. OOP is a way of writing code that let’s us create easy to mantain code, while letting make big projects. It’s used by a lot of mainstream programming languages, and if you join any Computer Science degree, you’re very likely to encounter (and struggle with) OOP early on in your journey.

Then we have the Agile movement. It is a bit younger than OOP, but it’s not young at all. Unlike OOP, Agile goes a bit further and attacks the way we do things in a project, not just code. I’ve said before that Agile methodologies are usually utopic in theory, yet hard to achieve in reality. But that doesn’t change the fact that it’s widely used in the industry, it really is a pilar of the software community.

So, why are they alike? Well, to start off, and I hate to be a negative Nancy, but both of these cool concepts are super easy to mess up. People use Java or C++ and think they are doing OOP, but we know that’s not actually the case. And there’s a bunch (like, literally everywhere) of development teams that use “Agile” methodologies, yet they’re just doing daily meetings and hoping everything works out for the best. Both OOP and Agile have huge world-wide conferences were people meet each other to talk about the current state of things in that area. OOPSLA is legendary, but I did some research on it and I guess it’s kind of defunct now? There is something called Splash which I think is the new equivalent of OOPSLA. The Agile conference just happened in August.

I have two main takeaways from comparing OOP to Agile. The first part is that both movements have a human element, and in an industry with so in need of that, they gather a massive amount of people that are interested in those two movements. What I mean by that is that they both feel like a community, and being a human is all about being part of different communities. Think about it. The people you go to work with are a community, same goes for your neighbors. Those guys you meet each Wednesday to play soccer with? That’s a community. A group of people that have one or several interests in the same stuff. And what are OOP and Agile? A community! So I think that’s an awesome part of the correlation between each other, and a massive part of why they have been succesful.

The second takeaway is that OOP happened first, and it wasn’t as deep as Agile. But the first people that used OOP eventually moved on in their careers and started managing instead of only creating code. So naturally, that was when Agile was born. It just makes a lot of sense. It’s almost like Agile is the next generation of OOP, but it’s obviously different from it. I just thought that was interesting, but I don’t know, maybe I went to deep myself.

I just wrote a lot of words. It’s really sad that this is my last blog for the course, but it won’t be my last blog. For the past 4-5 months, I’ve been working on setting my internet presence, and this blog will continue to be part of my strategy moving forward. So I hope the three people that read my stuff continue to be here with me!

The future is coming, and it’s going to be awesome.

Thank you for everything, professor Bauer. You rock.

Kent Beck had a video chat with my class

Yes, that Kent Beck. I’ve been very fortunate to have Ken Bauer as my professor this semester, and one of the cool things about him is he knows a bunch of cool people, including Kent Beck. So we had a very cool session with him, and it was one of the greatest experiences I’ve had in my student career. I just wanted to talk briefly about that, but let’s get on with the topic.

Simple things are often great things, and test-driven development does a lot of small things that inspire confidence. One of the first things I was taught in my Data Structures was how to solve certain problems using recursion, and one of the key giveaways that I got from that lecture was how recursion focused on splitting a big problem into smaller fragments, thus making the problem easier. TDD is similar in that we can use it to create massive systems and divide them into smaller tasks. By solving smaller tasks, which we call tests, our code usually is much cleaner than solving a chunk of stuff.

Keep it simple, stupid, is an awesome principle that is used in TDD, and I actually think it applies to a bunch of stuff in life, but I guess I’ll talk about that in another blog. Simplicity is elegant, and when you reach elegant solutions to big problems, life can be pretty good.

Another cool stuff about TDD is how code keeps improving all the time. There is literally a step for refactoring code that tells you exactly what to do to make your code more clean, more elegant. And in an industry where programmers are judged by how clean their code is, following the steps that TDD lays out is a great way to develop cleaner solutions.

Look, I could go on and on about all the great things about TDD. Heck, there’s even a whole benefits section in the Wikipedia for Test-driven development. That’s nuts! The influence that this way of doing development in the industry is huge, it’s everywhere, and it has a reason to be everywhere. When things are done right, it’s something incredible.

You can check out my work at grupoargon.co

Testing, but it’s object oriented

Systems come in all shapes, colors and forms. Some are big, some are small, and each requires a different strategy when it comes to testing, so it shouldn’t be a surprise that object oriented testing is a bit different than your regular testing.

We’ve talked about object-oriented programming a bunch, we know what it is, and how popular it is, yet there is not a lot of material on testing for object oriented systems. The beauty of OO testing is that it can be divided into three different branches, and we will cover all of them.

Let’s start with class testing, because of course we will start with class testing. A class is a key component of OO, it is the blueprint of how we will build stuff, and a beautiful way to organize code. So when we do class testing, we are basically checking each of our classes for errors or bugs that may give us headaches down the line. It is the way to validate that our class is following the design we have, and it ensures that every little part of our class, wether that be an attribute, a method, or an interface, is 100% bug free.

Then we have inter-class testing, and it’s a bit more complex than class testing. Your classes may be bug free when tested individually, but OO is all about interaction between classes and modules, so now you have to verify that all is well when the classes in a system are working together. Our system should be integrate, and inter-class testing is used to verify integrity.

Finally, we have system testing. At this point in our testing, we should have an integrate system, since we’ve already passed the inter-class testing. Now is the time to check upon the system’s compliance with the specified requirements that were defined in the analysis phase. Black Box testing is generally used to validate our tests during this stage.

As you can see, that’s a lot of testing! And I’m kind of tired of using the word testing, so that’s the last you will hear from it, ha.

Be sure to check out my website at grupoargon.co

Valid validation and verified verification

Hi there. During this wonderful 5 month journey, we’ve talked about software a lot, and we’ve mostly talked about how software is created. The industry expects certain things when creating new systems, and there is a whole process of normalization that exists out there. We’ve talked Analysis, Design, Implementation, but we’ve yet to talk about Verification and Validation, another key element of this beautiful process that we call building software.

It’s super common for any industry to have some sort of validation on products and services that are created. For example, the ISO 9001 is a quality control standard that many companies use to manage quality and show the world that their product is worthy. So my first action when doing research on this topic was to look for the different standards out there, yet my first google search didn’t yield exactly what I was looking for, so I just turned to the Software verification and validation page on Wikipedia, which actually has a decent structure on the topic.

Not this type of validation, but a meme is a meme

I wanted to talk about the difference between verification and validation, because apparently they are not the same! We use validation when we are the end of a development cycle, or when we are “finished” with the system. You can use it to validate that all the user requirements are fulfilled and that the system is full go. Verification is a bit more complex in that it handles the output of individual phases during the development cycle, so you use it to ensure that things are going the way that they are supposed to. Both are super helpful, yet I believe that verification can sometimes be biased depending on who is actually doing the verification.

Regarding the standards that I found, the first one is the ISVV, which stands for Independent Software Verification and Validation. It is aimed towards safety critical systems, and you can see that doing correct verification and validation in systems where potential lives are there for the taking is something really important. There is a reason that you do take an Ethics class during your degree. The cool thing about the ISVV is that their tests are done by independent engineers, so there is no bias going on during the process.

I tried searching for some other standards, but I didn’t find anything too specific, except for the fact that the FDA requires some form of verification and validation as well.

That’s going to be it for this blog, hope you enjoyed it, more blogs are on the way!

Be sure to check out my website at grupoargon.co