Author: carlosmartell97

Implementing Software

Well, just implement it! Right?
Title might seem too self explanatory (I thought that too), but no. Not necessarily. There’s more to this than what you might assume by just knowing what it’s called.


For what I’ve come to learn, correct me if I’m wrong, when you talk about software implementation you’re talking about the challenges a development team faces when implementing software. This, in terms of making the team work as one and that all code seems to have been written by the same person. This makes it a whole easier to understand what another member of your team is doing, how you can contribute, and measure the overall progress of your team because you all basically have the same way of organizing yourselves.
Let me go deeper into this…

These challenges I mentioned before are among these classifications:
  • code-reuse: a lot of problems arise when you’re faced with compatibility issues when trying to re-use code from somewhere else. And when trying to solve this, you’ll then have to think: HOW MUCH actual code should I re-use?
  • Version Management: It doesn’t matter if a new version of your software is released, you should never throw away all documentation you have on previous versions and configurations! You’ll want to go back at some point and check for something, you never know… That’s why you need your documentation to be highly accurate and descriptive.
  • Target-host: Yes. At times it’s going to be impossible to design a single piece of software that runs flawlessly on every user machine, but your design should still aim for that! The way you implement software should consider the multiple environments in which your software will exist.

Hopefully, you’re seeing the connection this all has with previous blog I’ve written Continue reading "Implementing Software" →

Test it first!



Title’s pretty self explanatory. Or, is it? software testing…
This can be a very fun process. You’re basically trying to break things from all possible angles. Find bugs and you’ve done your work correctly. Of course, the software development team’s work just doubled! Or maybe backstepped all the way.


Your responsibilities as a software tester are verifying and validating that a program, application or product pass all following tests:
  • meeting business and technical requirements upon which design and development were constructed (You see where everything I’ve talked about design and requirements in other blog posts gets us to?)
  • working as expected
  • possible implementation on multiple environments and use cases
No easy work, that’s for sure. If some bug gets to the users, not only will the software development team be approached, but software testers as well. Why wasn’t the bug discovered during testing?


Before I go any further, aren’t you wondering why computer bugs are called BUGS? I sure was...
What does the world have against bugs? Poor animals. Well, back in the day computers were as large as classrooms, actual real-life, living bugs were a huge problem in these monstruous computers. You got rid of the bug, you got rid of a problem on your program. Funny how these terms stick through history, right?




Perhaps I’ll be saying this in every blog from now on, but in a previous blog post, I talked about the Software Lifecycle. Remember? Please do :(
Software testing is an essential part of the SDLC. It is at this point (no matter the methodology) that you might find bugs that will throw you back some steps of the development process. Fix those bugs, test again, and pray it all goes Continue reading "Test it first!" →

Test it first!



Title’s pretty self explanatory. Or, is it? software testing…
This can be a very fun process. You’re basically trying to break things from all possible angles. Find bugs and you’ve done your work correctly. Of course, the software development team’s work just doubled! Or maybe backstepped all the way.


Your responsibilities as a software tester are verifying and validating that a program, application or product pass all following tests:
  • meeting business and technical requirements upon which design and development were constructed (You see where everything I’ve talked about design and requirements in other blog posts gets us to?)
  • working as expected
  • possible implementation on multiple environments and use cases
No easy work, that’s for sure. If some bug gets to the users, not only will the software development team be approached, but software testers as well. Why wasn’t the bug discovered during testing?


Before I go any further, aren’t you wondering why computer bugs are called BUGS? I sure was...
What does the world have against bugs? Poor animals. Well, back in the day computers were as large as classrooms, actual real-life, living bugs were a huge problem in these monstruous computers. You got rid of the bug, you got rid of a problem on your program. Funny how these terms stick through history, right?




Perhaps I’ll be saying this in every blog from now on, but in a previous blog post, I talked about the Software Lifecycle. Remember? Please do :(
Software testing is an essential part of the SDLC. It is at this point (no matter the methodology) that you might find bugs that will throw you back some steps of the development process. Fix those bugs, test again, and pray it all goes Continue reading "Test it first!" →

Patterns. Software patterns everywhere…

Ummm what?
I didn’t know what these were, either. After some research, I’ll now try explaining to you what I learned. Sounds good to you?

Again, this has a very continuous relationship with previous topics I’ve talked about before. Specially, you’ll find yourself thinking of software architecture (hopefully). Why? For starters, design patterns are something a software architect should always be able to identify. Let me too you why…

There are some reusable, optimized solutions to common programming problems. Solutions that people who build programming languages should also identify right away. This solutions I’m talking about are, in fact, design patterns. But all these people must be careful: “If implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior”. (source)

It’s important to know there are basically 3 types of design patterns:
  • Structural
  • Creational
  • Behavioral
Their names don’t say much, do they?

Structural patterns refer to relationships, how entities work together.
Creational patterns refer to the way mechanisms are instantiated, so each situation has its easiest way of object-creation.
Behavioral patterns refer to the communication between entities (please do not confuse these with structural patterns).

What I mean by “patterns” is basically past situations other programmers have been through. They’ve experienced the same, and now they know a solution for it. Why wouldn’t you want to consider their way of solving these problems?

Let me include a very illustrative result:


Imagine something like this in code-form. How many interfaces do you see? several.
But on the other side, in how many ways is this thing reacting to the several interfaces? One. Just one! This is precisely one example of the adapter pattern: “structural design pattern that allows
Continue reading "Patterns. Software patterns everywhere…" →

Patterns. Software patterns everywhere…

Ummm what?
I didn’t know what these were, either. After some research, I’ll now try explaining to you what I learned. Sounds good to you?

Again, this has a very continuous relationship with previous topics I’ve talked about before. Specially, you’ll find yourself thinking of software architecture (hopefully). Why? For starters, design patterns are something a software architect should always be able to identify. Let me too you why…

There are some reusable, optimized solutions to common programming problems. Solutions that people who build programming languages should also identify right away. This solutions I’m talking about are, in fact, design patterns. But all these people must be careful: “If implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior”. (source)

It’s important to know there are basically 3 types of design patterns:
  • Structural
  • Creational
  • Behavioral
Their names don’t say much, do they?

Structural patterns refer to relationships, how entities work together.
Creational patterns refer to the way mechanisms are instantiated, so each situation has its easiest way of object-creation.
Behavioral patterns refer to the communication between entities (please do not confuse these with structural patterns).

What I mean by “patterns” is basically past situations other programmers have been through. They’ve experienced the same, and now they know a solution for it. Why wouldn’t you want to consider their way of solving these problems?

Let me include a very illustrative result:


Imagine something like this in code-form. How many interfaces do you see? several.
But on the other side, in how many ways is this thing reacting to the several interfaces? One. Just one! This is precisely one example of the adapter pattern: “structural design pattern that allows
Continue reading "Patterns. Software patterns everywhere…" →

Ted Mosby, Architect.

This is related to the previous posts of mine about software design, so hopefully you know about this. What does this all have to do? A lot, really. One very cool sentence I saw on the Internet on it: “design completes the how that architecture doesn't (and shouldn't) talk about”.

Architecture is the bigger picture. It specifies frameworks, languages, scope, goals and methodologies. On the other hand, design is more specific; design plans how the code will be organized and how different parts of the system will look.

Software architecture is responsible for providing:
  • rules for how components and modules will be combined and how they’ll communicate.
  • reusability and partitioning solutions to frequent problems.


The common thing for these two things is that they should, SHOULD always be made after goals and requirements have been defined. It makes no sense to do it before. Any attempt to doing it before will most likely lead to necessary changes that will surely affect the efficiency of all your team.

Do you want to become a software architect? Here’s the intro to a short course for doing so!


If you wish to continue reading about this, you can! The sources I used might lead you somewhere:

Ted Mosby, Architect.

This is related to the previous posts of mine about software design, so hopefully you know about this. What does this all have to do? A lot, really. One very cool sentence I saw on the Internet on it: “design completes the how that architecture doesn't (and shouldn't) talk about”.

Architecture is the bigger picture. It specifies frameworks, languages, scope, goals and methodologies. On the other hand, design is more specific; design plans how the code will be organized and how different parts of the system will look.

Software architecture is responsible for providing:
  • rules for how components and modules will be combined and how they’ll communicate.
  • reusability and partitioning solutions to frequent problems.


The common thing for these two things is that they should, SHOULD always be made after goals and requirements have been defined. It makes no sense to do it before. Any attempt to doing it before will most likely lead to necessary changes that will surely affect the efficiency of all your team.

Do you want to become a software architect? Here’s the intro to a short course for doing so!


If you wish to continue reading about this, you can! The sources I used might lead you somewhere:

Yeah… Software (de)sign

Ok, hear me out. I’m now going to talk about software design and software architecture. Are you interested? Good.

First: design. This means the process where you transform gathered user requirements. This is made through a Specification document. I’ve talked about this in past blog posts, remember? Please remember :( so why am I talking about it again? Because I still have things to say…

Software design leads to 3 different levels of results:
  • Architectural: highest abstract version of a system. This just helps designers get the idea.
  • High-Level: Less abstract view of subsystems and modules. It takes into account all components.
  • Detailed: Here details of how the implementation should be made. Defines a structure and interfaces for modules to communicate with each other.
It’s here that you might want to think about modularization, dividing a software system into multiple, independent modules. This makes it easier to maintain and reuse. And more importantly, it leads (ideally) to parallel executing! With several modules, there’s not just one sequential sequence of steps running, as each module is independent and able to do it on its own. Isn’t this awesome?


How do I know all this? I read it. I researched. You want to know more? Go ahead! These were my sources:

Yeah… Software (de)sign

Ok, hear me out. I’m now going to talk about software design and software architecture. Are you interested? Good.

First: design. This means the process where you transform gathered user requirements. This is made through a Specification document. I’ve talked about this in past blog posts, remember? Please remember :( so why am I talking about it again? Because I still have things to say…

Software design leads to 3 different levels of results:
  • Architectural: highest abstract version of a system. This just helps designers get the idea.
  • High-Level: Less abstract view of subsystems and modules. It takes into account all components.
  • Detailed: Here details of how the implementation should be made. Defines a structure and interfaces for modules to communicate with each other.
It’s here that you might want to think about modularization, dividing a software system into multiple, independent modules. This makes it easier to maintain and reuse. And more importantly, it leads (ideally) to parallel executing! With several modules, there’s not just one sequential sequence of steps running, as each module is independent and able to do it on its own. Isn’t this awesome?


How do I know all this? I read it. I researched. You want to know more? Go ahead! These were my sources:

UML, visual help…?

UML. Unified Modeling Language. Shortly, it’s a visual modeling language. It’s very common for business analysts, software architects and developers to use it. It helps provide guidance for team’s activities (specific developers) and can also help monitor and measure team progress!

Used software engineering in general, but more specifically in object-oriented software, it shows an application structure.
This will basically help you visualize your classes, and easily communicate to others the structure and content of a class, or indications of what these should be.

As an example, this is what an UML class diagram for some “Employee” class would look like:
Nice, huh?
  • The top rectangle contains the name of the class desired.
  • On the next rectangle we can see its instance data, its state.
  • But we also need specifications for Employee’s behavior (methods needed to access its information), and so it’s specified on the next rectangle. Here you can see a constructor method, as well as some getters. Setters are not specified, but they would also be listed in this rectangle.
  • Did you see the signs at the start of each line of these last 2 rectangles?
    • MINUS means private!
    • PLUS means public

There are 14 types of UML diagrams, though. Here’s a list of some of them:
  • class diagram
  • use case diagram
  • object diagram
  • sequence diagram
  • state machine diagram
  • activity diagram
  • package diagram

All 14 types can be classified into 2 main categories: structure diagrams and behavioral diagrams. Structure diagrams shows the different objects in a system, whereas behavioral diagrams describe how objects interact with one another…

Authors: Carlos Martell, Hermes Espinola, Jesús Alvarez, Juan Melendres & Alejandro Güereca

To take your reading one or many steps further, you can start reading through these sites, our sources for this post: