The Software Engineer

I would like to make it clear that my intentions are to advocate software engineering through this blog. Having worked for about 3 years under the title of 'Software Engineer', I realized that it is a little more than just programming. However what I did was mostly programming. On the other hand, I have been working since 5 months using the title "Web Programmer" while most of what I was doing should be considered software engineering. I have been involved in planning, requirements elicitation, process engineering, architecture, data migration, database design, user interface design, and also programming (in a language I had very little prior experience in: remember learnability!). I smirk at the irony. Around the world, over the years... It has been over two months since my last update. Yeah, I know that I say that every time I post something new. This time, I decided that I would rest it out and see what other bloggers have to say about software engineeri

Adapt or perish, now as ever, is nature's inexorable imperative. -H G Wells I have been away for a while: had a lot of coursework to complete and I am finally out of it unscathed. Hi everyone, welcome back. As usual, I will begin my rants with the disconnect between the job market and the definition of a software engineer. Recently, I received a call from a company (which I do not recall applying to) asking me "In which technology are you a software engineer?" It is the same as asking an automobile engineer, "In which type of vehicle engine are you an automobile engineer?" Specialization, you say? Not really. Although automobile engines do not evolve as fast as programming languages, an engineer must be ready for all. (S)he is the one who should make the decision regarding which is most suitable. It basically undermines the factor of learnability within the engineer. Is it not possible that an engineer learn about a new technology and imp

I started writing this blog in order to explain what software engineering is. I have noticed that most people use the words "software engineer" to describe a person who is basically a programmer. Unfortunately, that is a misguided definition of software engineer. I have attempted to clear that fog in my previous post. However, no matter what definition is used, what is it that we really need? A software engineer or a programmer? This post, however, will take a tangent into one aspect of Software Engineering: Requirements Engineering. You can learn more about requirements engineering here - http://en.wikipedia.org/wiki/Requirements_engineering Requirements can be divided into two broad categories: functional and non-functional. Functional requirements are those details which form the basis of the software being built. This consists of the main reasons why the particular product is being developed. As an example, one of the functional requirements of the Amazon Kindle read

I have been tweeting about this a lot since the last few months. However, through sources such as recruitment portals, I have noticed that many people still do not understand the difference between computer science and software engineering. First, to clarify the difference between engineering and science: A scientist invented the wheel. An engineer put four of them together and invented the car. Scientists will focus on specific aspects to gain a deeper understanding of the subject and in the process discover new things or invent a new primary artifact. Engineers, however, will use this knowledge and artifacts to build complex systems which can be put to use directly. Both domains are equally important but we must understand that while one is deep, the other is wide. Sciences are verticals while engineering is an all-encompassing horizontal. Similarly, when we think of computer software, we must understand the difference. Computer Science gives rise to the verticals