Sunday, August 19, 2012

Around the world, over the years...

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 engineering. (I despise using the word 'blogosphere', a quick xkcd comic for that: http://xkcd.com/428/)

To begin, I read a blog post by Matthew W. Johnson titled "Engineering Icons, not Programming": http://imagine.kicbak.com/blog/?p=193 . I found that he made the same points as I made when I started this blog. Matthew begins to compare software engineering to civil engineering and brings in a bridge analogy. This made me question that who would make a better software engineer: A computer scientist or an engineer in another field? Understanding the facts that a regular engineer will be familiar with the general concepts of engineering and would apply them to his or her field while a computer scientist will be an expert in understanding computers and software programs. In fact, I have met a few people with no formal programming background become better software engineers than those who do. This might be a question for debate.

Another article which I found interesting was by Steve McConnell (author of various textbooks on software development and its aspects) written way back in 2004. http://www.stevemcconnell.com/psd/04-senotcs.htm . This was particularly interesting to me because McConnell would ask candidates questions related to software engineering during recruitment. He further goes on to explain how software engineering should evolve out of just plain development. To add to that, there are other project objectives that should be met. 

I would like to find counter arguments to software engineering which may bring about a healthy discussion. However, till then, I will try to update about more of the nuances of software engineering.

Cheers!


Sunday, June 3, 2012

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 implement it? Hath not an engineer brains?
I got carried away by a bit of Shakespeare there.

However, the point I am trying to make is this: The technology is disposable. Especially in software development, where they get outdated really fast, we need people who not only have development skills  but at the same time, engineering and reengineering skills along with learnability of new technologies.

One common example of outdated technology is that of the Enterprise Java Beans or EJBs. It was (and still is) a server-side managed component architecture for enterprise applications (http://www.oracle.com/technetwork/java/javaee/ejb/index.html). Till about 2008, EJB was a highly demanded skill for "software engineers". However, it didn't take much time to die out and one would hardly see any new positions requiring knowledge of EJBs. Soon people realized that EJBs were not practical for real world applications and EJBs went out faster than lightning.

So, what happened to the knowledge gained by people who were experts in EJBs? Panic and rushing towards learning the next hot technology? If we learn by experience, we must note that adabtability and learnability should be focused on by companies.

A software engineer will provide that. One of the things that a software engineer does over a computer scientist is evaluate tools. There should be enough reasons to select a particular language and then develop in it. The focus should move away from coding and towards software development.

In fact, IEEE Computer Society's Certified Software Development Professional Certification Program (CSDP: http://www.computer.org/portal/web/certification/csdp) has the following elements:
  1. Business practices and engineering economics
  2. Requirements
  3. Design
  4. Construction
  5. Testing
  6. Maintenance
  7. Configuration Management
  8. Engineering Management
  9. Engineering Process
  10. Tools and Methods
  11. Quality
Out of 11 elements, just one element (Construction) deals with programming. Even there, it is elementary to select the appropriate language or technology before development.

Adaptability and Learnability are two important virtues of a true (software) engineer.

Cheers!

Monday, April 2, 2012

Non Functional Requirements are People too!

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 reader is to open e-books. Another one would be to display the pages in the book.

Non functional requirements are those properties required from the software product which the functional requirements to execute smoothly. These do not form the core requirements of the product but are essential to the performance. With the example of the Kindle, we can say that displaying the pages at different resolutions clearly is a non-functional requirement.

If we can recall the chart from my previous post, functional and non-functional requirements can be mapped as verticals and horizontals respectively. This is a similar diagram for an e-book reader:






I have observed this general notion: People automatically assume "Non-Functional Requirements" as "Non Requirements". We conveniently drop the word "functional" and treat NFRs (Non-Functional Requirements) as trivial elements.

These do not affect the business logic of the software directly. These do not form the core functionality of the application. So, we assume them to be unimportant. DANGEROUS!

I would like to emphasize that NFRs are very important to the system being developed. In fact, in some cases, they are more important than the functional requirements themselves.
Consider a banking application. If we do not provide adequate security, citing that security is non-functional, we might as well go bankrupt. Many argue that in this case, security is a functional requirement. However, I maintain that the main requirements from the bank are to store one's monetary assets and enable transactions on those assets. Having them do that securely is an extremely important, yet non-functional requirement.

I think that I have repeated myself enough on this. However, I would like to summarize that the importance of the requirement is not evident from the categories of functional or non-functional. This depends upon the nature of the product and the priorities set by the software engineer. Security is generally an important requirement from most products (esp. on the internet). However, security is a non-functional requirement in most cases.

NFRs are people too!

Tuesday, March 6, 2012

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.