Remember the history of software engineering? Oh yeah, I remember!

Some people don’t realize this, but software engineering has been around for quite a while now. The roots of the whole discipline began at around the 60’s. People only used computers for calculations, and computations (Duh) for scientific projects. However, people started to notice that there was a lot of potential in computers, and started to see things around it. That’s when the idea of software engineering appeared.

The whole thing about people now making software in order to optimize the use of the machines sounds really cool doesn’t it? Well it was, however the transition wasn’t pretty. A lot of people had been working for a while now in the development and the maintenance of hardware, but with the new trend of software some of them needed to adapt. People without experience had to start getting the hang of the idea of developing software or there would be no bread for them. People that knew software were scares. Not only that, but people didn’t really know how to write software at all. All they had was a black page, and a goal. People were looking for a “silver bullet”. The ultimate solution that would solve the problem during this software crisis. This went on from 1965 to 1985. So a really long time. During the following years, people notice that there would be no “silver bullet”. There is no magic key to success. People now adopted the idea that technologies and the different branches from them are there to increase productivity and quality in areas.

With the goal now clear. Developers found different ways of achieving this. Things started to progress in a positive matter. New tools where developed. Something that marked a big growth in the development of

Continue reading "Remember the history of software engineering? Oh yeah, I remember!"

What is software engineering?

“Sometimes science is more art than science. Some people don’t get that” – Rick Sanchez

I remember that since high school I questioned myself whether programming was an art. It felt like a very scientific, and non-artistic when I first had the concept. Now I would like to remember that back then I thought that programming was some kind of crazy witch craft that only geniuses could do. Which is not true at all. Now, I hold really close the idea that anyone can code. Anyways. After that I came to the realization that programming is some way of art. To a certain degree I think it’s both; a discipline, and a craft. At the same time it’s a form of art.

Now, why is it a craft? To certain degree, like I said before, everyone code. So coding is more of a craft than a discipline. It really isn’t that hard. You learn how the language processes the commands, and learn the syntax, and you’ll be good to go. It is also a discipline, because in order to properly make good software engineering, it’s necessary to know a lot more than coding. You need to learn the process, how to work, how to communicate, how to be empathetic. There’s a lot more to learn in software engineering than just programming.

The art part of it. I have this discussion with some of my friends every time we stubble into a subject related to it. Software engineering is an art for various reasons. For starters. A software engineer must find the most elegant, practical, and efficient way to solve a problem. That’s the main plate in the idea. Someone once told me that software engineering is a bit of a mutt.

Continue reading "What is software engineering?"

Software Design, can’t really think of a pun right now

So today I will talk to you about software design. Again, it’s not that much of a complicated idea to get around with. With design you gathered all your components and requirements for your peace of software. You tend to do this on a specifications document, where you specify your design. Not very complicated really. So the whole idea of the design can be deconstructed in three stages:

  1. Architecture, where you have an overall, and broad understanding of your project’s functionality and requirements.
  2. The High-level, in this level you start to see more specific view on the modules, and subsystems of the project.
  3. Detailed. I think that it’s a bit of the given this one, but okay. You see each subsystem specifically and you have a detailed description of the implementation that your project should have.

Before going into my point of view about this subject, and overall discussion about it; I want to thanks Carlos Martell for his blog post about this subject, because it helped me to clear some ideas about it. Go ahead, and check it out, he’s pretty good at writing. So design is cool, because once you have it you can easily visualize the project. There’s less ambiguity. Also, when you have it in a good system you can treat each subsystem as it’s own, and set interactions between them. So it’s easier to understand, and also easier to implement. I’m not very much for planning and design. However, in big projects or implementations. So yeah, it’s pretty neat.


Well that seems functional

So in any project that you’re working in something really important is to know how the project is going to work. With this said, having a clear knowledge of the functional and non-functional requirements for your project. Now, what are the differences between functional and non-functional requirements, you ask? Well let me explain. To have things crystal clear functional requirements are those that you have for your project’s functionality. In a more non software engineering example, it’s like when you have to prepare a presentation. Your information is your functional requirements. You need that stuff in order to properly portray what you are presenting. Now, the non-functional requirements is everything that makes your stuff pretty. Again, in the weird presentation analogy this would be making things pretty. Maybe using a Prezi for your visual aid. Using a whiteboard while you talk. Stuff that aren’t really necessary, but they are nice to have.

So functional requirements focus in what is the software meant to do, and the nonfunctional requirements in certain qualities of the software. This qualities can be divided into two categories:

  1. Execution qualities, such as security and usability, which are observable at run time.
  2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.