Software engineering

This is something I wanted to talk about and discuss since quite some time.

Software engineering is one of the engineering disciplines and qualifies to be one because like any other engineering discipline, it applies knowledge to solve practical problems. Having said that, software engg. is also very unique from other engg. disciplines.

While every other discipline be it electrical engg, mechanical engg, civil engg, architectural engg or aerospace deals with the creation(design and construction) of something very tangible, software engg. involves creating software, which can be perceived only by the mind.

It is this inherent quality of software that makes it extremely appealing to me. (I can be dramatic here and draw analogies between software and the wind, fire, energy but will refrain from doing so ;-) ). Software has no intrinsic physical structure, no rules are imposed on it by nature and it has an ethereal existence. Whatever structure it is perceived to have, we impose it.

And this is why, I feel, it is very important for a software engineer to have a basic philosophy, a fundamental paradigm, which dictates how he/she looks at software. What does a function, a variable, an API mean in the larger sense? What is it's name? What are its characteristics, features and qualities? How does it behave? What does it do and not do? How to use it, when to use it and who should use it? When these questions are answered, software comes to life. It ceases to be ethereal and comes into verifiable existence, but only to those who know the answer to the above questions.

I can give an interesting example of a colleague whose paradigm of looking at software is to treat it like a fellow human being. And it's a good one because all the above questions are very valid questions that can be asked about any human being. This colleague of mine talks about functions or variables like they are people! He uses terms like kind, strict, suspicious, funny, smart, fair, partial and many more to describe these things! (You could of course call it bad sense of humour also ;-)) He really thinks of them as we would think of real people we know. And the best part is that a lot of times, he's able to figure out how the system will behave(or should behave) in a certain peculiar situation without even looking at the code because he knows it like he knows his friend!

A strong perspective like that really helps in understanding and designing software intuitively. And it also makes things easier when you are trying to fix 10x bugs in x days!

Anyway, my point is that a software engineer must be able to look at software as some tangible entity, something real, concrete and must feel the life in it. To make the ethereal work with, for and like the real. That's the challenge.

This is the domain of analogy. Decide between what.