--Originally published at Computer Systems Engineering

When we want to develope a program, the best thing we could do is follow this phases that we call program developement life cycle. This cycle consists of 6 steps:

1. Problem definition
2. Analysis
3. Algorithm Developement
4. Coding and Documentation
5. Testing and Debugging
6. Mantainance

1) The planning is the most fundamental part, we need to analize the problem, this is the key: focusing on defining the problem before thinking about the solution. It has to be very clear what are we  trying to solve, put boundaries to the issue, understand the problem and what the solution must or mustn’t do. Unfortunately, this is often the most rushed part for us young developers because we just want to start working right away and we throw a solution really quickly without taking our time to understand the problem that we have to resolve for the client.

2) On the next phase, analysis, we start defining the goals as functions for the program. This is when we link problem-solution, we also need to look into posible issues that could rise when meking the project. It’s in this moment that a Software Requirement Specification document should be created, but in reality as students, if the teacher doesn’t ask for it, who actually bothers to  make one?

3) In the design phase we see more technical stuff like data flow, modules and the architecture of the problem solution overall, when we make this of course we need to take into account the things that were defined on the previous phases

4) Implementation is the phase we look forward the most (or at least that’s waht i think) because we start creating the solution and we can actually see progress. We see code being written as work being completed which is different then the previous

Continue reading "Life Cycles" →

--Originally published at Computer Systems Engineering

Let’s get started with this LONG chapter 5 of the book.

Software needs to change, that is innevitable, let it be because some new features need to be added, some need to be updated, some need to be added, deleted, or whatever.  They tell us to be ready for the change but in reality we are all panicked about change.

In object oriented programing a way we can prepare for that change in software is using abstract classes that can act as placeholders that when we put to use we can modify to fit our needs. The abstract classes defines the behaviour and the sublcasses are the ones that implement the behaviour.

Another alternative to make software chaengable is using interfaces, which makes it more flexible and addaptable, perfect for the case that the book brings up about needing to add various instruments, by creating an interface you can be ready even for those sublcasses that doesn’t exist yet but if you try to make your code bigger they for sure will be usefull to avoid code duplication.

Joke break. On the left we see how flexible we want our code to be, on the right we see how flexible our code actually is:

Encapsulation is important to leave some parts of your code unbothered while at the same time you leave some other parts run free for every change necesary. It’s vital to know and analize your code to diferenciate which will actually stay as it is and which will need an update every hour.

Everything is about following the OO design principles, make your code more flexible and think things trough. We shouldn’t be stubborn about keeping our design as it is only because at a given moment it worked, we need to improve and better to

Continue reading "Nothing Ever Stays The Same" →

--Originally published at Computer Systems Engineering

Let’s talk about chapter 4 of the book.

In this chapter they talk about putting your software to use in real world because, you know, world isn’t the perfect environment we all want it to be. We can try to prevent as much as we can some software malfuctions that our system may have by doing this: ANALYSIS.

We need to carefully think about where is our program going to be when it is no longer in our little bubble of perfect conditions, we need to train it and prepare it for all the scenatios, create new use cases, update the ones we already have and basically give our program a shield and a sword so that it can fight the world. Visual representation of our program:

As for my personal thougts, i think its really important to get used to preventing things on a larger scale. We are in a risk of getting acostumed to programming only taking into acount that it should work for the school project, or that it only has to work well on our own computer but that’s not how it works at the end of the day.

Without nothing else to say, thank you for reading and bye.

--Originally published at Computer Systems Engineering

Let’s get started with the third chapter from the book.

In the chapter they mention the situation in which you biult a perfectly functioning aplication but after it is used it is required to change because now the client wants something different. The be like “hey remember that thing you did? yeah i want you to change everything, hope it’s okay”. This is you after hearing that:

This is the reason why we should make code pretty, because when we need to modify it it will be 1000 times easier.

I was thinking about how many times my code is a mess because i just want to finnish it fast and forget to comment and clarify what things are what. Baiscally i set me up so that the next time i look at it i know absolutely nothing about how it works.

The thing is that, just how they mention in the book, software should be ready to change at any given time, be it because something should change or something must be added. When you writte good code you can use it again to build on top of it, it eventually saves you more time to be carefull and comment everything necesary than trying to be done with it and neglect those things. (I am guilty of that )

 

On another note:

I also enjoy that the book has those kind of titles that could be something else, that apply to situations outside software engineering. Like, i love that you could learn another lesson in life by reading this particular title “I Love You, You’re Perfect… Now Change”. Somethimes we think that we are in love with someone and they are in love with us, but they just keep telling us how to be and behave, changing us

Continue reading "I Love You, You’re Perfect… Now Change" →

--Originally published at Computer Systems Engineering

Just the title of the second chapter of the book already tell us a lot: the clients are innocent and only ask for what they want, telling us especifically what that is.

Am i right? (As if)

How many times has it happened that a client asks you for something and you spend hours doing exaclty what they asked just for them to reject it once you deliver because “It’s not what they asked for”. That for sure will make you angry at the client but you should be angry at yourself too. Think about it, whose fault is it? All the responisbility is not on the client, it is a mistake not to ask enough questions and asssume that that’s how they want it. You end up with a product no one wants and you end up like this in front of the costumer:

 

To avoid this kind of situations is why we need to learn to gather requirements. A requirement is “a specific thing your system has to do to work correctly”. Basically there  are the things the client ask for, so of course we need to listen to the client in order to know what the requirements for a specific product are.

When you speak to the customer about what they want we should make a requierement list, mention it to them and see if both sides are  on the same page. Those requirements are not set in stone, they can change depending on how the product is being developed and additional ideas or second thoughts of clients. That’s why constant comunication is needed.

I havent worked on a mayor project but it sure has happened to me that we divide tasks for some project with my team mates and each “agree” on what we need

Continue reading "Give Them What They Want" →

--Originally published at Computer Systems Engineering

In this post I’ll be talking about the first chapter of the book “Head First Object-Oriented Analysis and Design” and what were my thought about it while reading it.

There is a lot of things that may come to your mind when someone asks you what is “great software”, for me the first thing that comes to minde is that THAT is the type of software i want to write. I’d love if I wrote a program that made other say “that is great software”. But I don’t have a clear idea of what it means. In the book they point out some characteristics of great software that can be:

• It does what the customer wants it to
• It is well designed, well coded and easy to mantain, reuse and extend

So, how do we make what we write “great software”? well, we build a program to do what the customer wants while using oop principles and make it readable, reusable and extendable. As simple as that right? Just in theory really, now I realize that a lot of the OO code I have written can’t be considered “great software” #shame

Reading more of the chapter I encountered this phrase: “Don’t create problems to solve problems” and, as obvious as it sounds, i found myself remembering all the times i did just that. I just wanted to make the program do what it was supposed to and be done with it, even if it meant hard coding some parts of it, because i didn’t have to worry about using them again, i’ll pass the course anyways (what a bad way of thinking i have).

It is vital to learn to plan ahead of time before going all in and start writting the code, we need to stop and think about

Continue reading "Re-learning Object Oriented Programming" →