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!"
“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?"
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:
- Architecture, where you have an overall, and broad understanding of your project’s functionality and requirements.
- The High-level, in this level you start to see more specific view on the modules, and subsystems of the project.
- 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.