The Challenge of Emotions in Software Development

Should we bring our emotion when working in a software development team? This is probably a questions that pops up in many people’s mind in one way or another. In this case the emotions I’m talking about are pride, ownership and frustrations. There is a believe that when working as a scientist or engineer one should not bring emotions into work and when anyone made a mistake, they should be made accountable so that the issue can be rectified as fast as possible. I’m writing this based on my personal experiences and in hope that you as the reader can find some ideas, should you come across this dilemma.

Emotions are Waste of Money, is this True?

In some respect I have to say that I agree, that too much emotions can hinder productivities. Let take for example, a developer that takes a lot of pride in his/her work and has developed a piece of software. Unfortunately the software that has been developed does not satisfy the client’s requirement. It works well, but it does not solve the issue. As such, there are change requests coming in and criticism flows.

With the above scenario, if the developer took too much pride and emotions into the software, he/she will be very resistant to making any changes. Conflicts will happen within the team and the clients (be it internal or external) will not be very happy. Internal conflicts are great waste of money.  On the other hand, if the developer does not put any much emotions into the product then any changes can happen quite quickly.

As another example, having a dedicated testing team is a very common practice in a lot of organisations. The testing team is of course, a group of people who can professionally test products according to the specifications and often to the very little details. This is expected of course, this is why organisations spend a lot of money on testing teams. However their issue reports could be met with resistant, again this could be because the developer put too much pride into their product; just like an artist taking immense pride in their piece.

If we look at the above examples, one can conclude that if every developer works like an emotionless machine, then all issues can be fixed without resistance and hence no time or money wasted. Is it true though? Let’s take a look at what happen if we flip the coin 180 degree and go to the others side completely.

No Emotions can be Disastrous!

Just like the last section, let’s use another example scenario. A developer is working on a product together with a group of clients. Like in many situations, clients change their minds a lot and quite frequently do not know what are the correct ways to develop a piece of software. This can lead to a situation where there are great numbers of change requests being logged every time a new idea come up.

If the developer follows our previous theory and not taking emotions into the work, it’s possible that every change requests will go through and the developer will work on them straight away. Imagine if that happens! True that each change requests turnaround will be quick, but the project will drag on forever.

Not having any emotion or pride can also lead to substandard quality of work. Everything will get done just to the level specified in the specifications. I believe the humans are able to achieve great things only when they have pride in their work. Of course, if you take emotions out of the equations, this is not going to happen at all.

Last but not least, a person that does not have any emotions will not care about other people’s feelings. This can lead to in-fighting within the team. I’m not saying that we should always be polite and can’t be true to ourselves and team; however some courtesy is needed.

As an example: pointing out a problem on someone else’s codes can be done in two ways. The emotionless way is direct, like: writing code comments with the developer’s name and ask them to fix it or blame the developer in public or write in the public message board about the issue. This way can work if everyone doesn’t care or have any emotions, but I don’t think this is the case most of the time. The second way is the more “soft skill” approach, such as talking in private about the issue, post our suggestions without naming the original author and many other ways.

Balance it

It’s quite clear from both sides of the arguments that all of us needs to balance our emotions in a software engineering team. Have some prides and emotions about your products but keep an open mind for suggestions. Be courteous with other people within your team and you will find everyone is more open to suggestions and changes.

I like to think that when emotions overcome us, our minds are clouded and therefore we will not be able to come up with great products. So when this happens, take a step back and relax and think objectively. On the other hand when creating a product, always have some emotions when doing it. You will find that you will go above and beyond expectations most of the time.

So that’s emotions in software engineering, I hope that this article can be a fruit for thought for those having similar experience.

Categorised in: Business Process