Software Engineering is not Computer Science.


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 while software engineering is how we integrate these different technologies to build the software product. 

Here goes my controversial statement for this entry: “To a good engineer, technology is disposable.” This means that, for building a car, you may use one type of wheel for one but easily feel that another type of wheels are better for another car. This factor is very important in software engineering. But first, what is software engineering?

According to the 2004 Guide to the Software Engineering Body:

Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Too technical, eh? Well, basically a software engineer will choose the best practices and the best tools needed to build useful software. Tools may include: Process standards, design standards, software architecture standards, programming languages and testing standards. Yes, I said programming languages. A lot of importance has been placed till now on the individual knowledge of programming languages. However, to a real software engineer, languages are mere disposable tools. This is where one of the most important aspects of software engineering comes up: learnability. 

I emphasize on the fact that technologies get outdated because of innovations by computer scientists. However, a software engineer must adapt to these technologies and use them as tools to build software. One does not code/hack/develop software; one builds it. 

I hope I have brought out the basic differences here. Soon I will update with topics such as how Software Engineering relates to other fields such as Business Management and Psychology.

Feel free to criticize/comment. However, please maintain decorum with the words used.

Thanks.

Comments

Post a Comment

Popular posts from this blog

Software Architecture Patterns: MVC

Image
Long since I have updated here, I went through a number of experiences to land up in developing within the Android platform. Being pushed out of my comfort zone of server-side and database development, it is a fresh adventure by itself in developing mobile applications. Away from my usual rants about software engineering, I would like to be a bit more specific about a topic. Software architecture can be defined in a number of ways. The software engineering institute has compiled the modern as well as the classical definitions of software architecture. http://www.sei.cmu.edu/architecture/start/glossary/moderndefs.cfm http://www.sei.cmu.edu/architecture/start/glossary/classicdefs.cfm To be concise, software architecture is a set of models which define the highest level of system abstraction. This may begin with understanding the qualities of the required system and the tactics that enable those qualities. The summed up architecture document will consist of static views such...
Read more

Scrum: The Art of Doing Twice the Work in Half the Time

Sutherland, Jeff, & Sutherland, J. J. (2014).  Scrum: The Art of Doing Twice the Work in Half the Time . New York, NY: Crown Publishing Group. https://www.scruminc.com/new-scrum-the-book/ Introduction  The author, Jeff Sutherland, along with Ken Schwaber conceived Scrum as a method of improving productivity in software development teams in the early 90s. Coming from the horse's mouth, one gets an insight into the history behind Scrum and how the author evolved the process with every project he worked on or consulted for. One also gets to view the process through Sutherland's eyes as he applies that to every project. He provides ample anecdotes to supplement his arguments towards using Scrum as the process of choice not just in software development but also in other engineering as well as non-engineering domains. That said, it also brings about a bit of a confirmation bias of Sutherland regarding the efficacy of Scrum. Through the reading of the book, one desire...
Read more

Learn to adapt and adapt to learn

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...
Read more