Skip to main content

123 posts tagged with "software engineering"

View All Tags

Software Bugs - Some History

Published: · Last updated: · 2 min read
Robin Alex Panicker
Cofounder and CPO, Appxiom

That computer programs could have errors is a thought as old as computers. In a note dated 1843, Countess Ada Lovelace, world's first computer programmer, explained how Charles Babbage's Analytical engine could generate wrong output not because of any mistake with the device itself, but because it could be given wrong instructions. No wonder one of the most common and important features in programming languages is 'error handling'.

The first ever written reference, as available today, of 'bugs' is in a letter written by Thomas Alva Edison to his colleague in 1878. No, not the living 'bugs'. This is about 'bugs' as in 'failures', 'errors', unexpected results' in the non-living world of atoms and bits.

Edison writes ...

It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise-this thing gives out and [it is] then that "Bugs"-as such little faults and difficulties are called-show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.Those days it meant mechanical errors and problems. First time the term was used in computer domain was in 1947. This was when Grace Hopper reported the root cause of a problem in the electromechanical computer Harvard Mark II to the presence of a moth trapped in a relay. Soon the word entered the common lexicon of computer engineers. Initially the term was used for hardware problems.

But it was the software engineers who took 'bugs' to its current popularity. Now we even have a whole industry built around software bugs. This includes bug detection, tracking, resolution, testing and so on. The objective is to provide the end users with a clean experience by early detection and fixing of bugs. The interesting fact is, as more bugs get fixed, even more bugs manifest.

Team Appxiom is happy and proud to be part of this 'bug' industry.

Securing Remote Work

Published: · Last updated: · 3 min read
Don Peter
Cofounder and CTO, Appxiom

Ever since the pandemic began, most developers have been practising the art of remote working. While we continue to enjoy the flexibility to work in our own times, at least some of us tend to overlook the fact that our home systems can be vulnerable to cyber threats. So I thought I should share some security measures that I took as part of the remote working policy of my company Appxiom.

Check-in code frequently​

My laptop failed one not so fine morning. Luckily for me I was able to get on to a new machine in no time, thanks to my habit of frequent code push to Git. This habit helps. Do push the code as frequently as possible.

​

Keeping machine software up to date​

By being outside of the office’s secure network, keeping all softwares in your devices up to date is important, which otherwise would expose our laptops to potential attacks.

AWS Virtual workspaces​

I started using their desktop-as-a-service (DaaS) solution Amazon Workspaces, and my team is also moving towards that. It provides on demand secure desktop terminals on a hourly or monthly basis. The best part of using Amazon Workspaces was that it provided me with machines that were configurable for specific tasks. We used their service for our Android and Web development activities.

​

Updating default passwords​

Despite having all the necessary software and hardware firewalls installed on our machines, many forget to change the default passwords. I changed default passwords of all my services and devices, including my home wifi router. This might feel like a silly thing to do. Recently there was an incident at Nissan which proved otherwise.

Using Multi-Factor Authentication (MFA)​

I further stepped up the security on my digital assets, by enabling the two-factor authentication option wherever possible, so that I will have an extra layer of security in the worst-case scenarios.

Ensuring a secure WiFi connection​

I have always relied on either my home WiFi connection or 4G dongle for my internet needs. In case of unavoidable travels I carry my dongle, and make sure not to use public WiFi connections. Because you never know who controls those access points.

We developers are better prepared for a pandemic like COVID-19. Transitioning into a more technology-enabled new normal was a major challenge that probably everyone faced last year. While the pandemic disrupted the functioning of most other domains, software development more or less remained the same. The reason was that our work was well suited for flexible remote work environment and we developers were very much aware of available technology and collaboration tools.

We need to be better prepared to face the coming age of cyber threats while working in a remote working environment. After all, technology is evolving and so are cyber threats.

How Not to Be a Stupid Software Engineer.

Published: · Last updated: · 4 min read
Robin Alex Panicker
Cofounder and CPO, Appxiom

Source code of most of the applications used internally by a global company got leaked out a month back. Reason, someone there was careless and stupid enough to leave the default account credentials of the code repository as, wait, 'admin'/'admin' !!!

And one of the leaked applications was a data analysis tool that analysed prices of their products. How did they do that? By scrapping a public website owned by them !!! It's like stealing from one's own bank account, is it not?

I guess the global major is still figuring out how to clean up the mess.

A bank wrongly paid out $900M to lenders on behalf of their client. Blame is on the bad UI / UX of the software that was used by bank's staff which resulted in this transaction !!! Court ruled that the bank cannot get back the money. That means the bank cannot claim back the disputed $500M of that $900M. Judge even called the incident as biggest blunders in banking history.

There was a news report couple of years back that the combined wealth wiped out because of failed digital transformation efforts in global majors is north of $900B !!!

While naming any of these companies is out of scope of this blog and hence avoided, all the above mentioned are widely reported and can be googled.

Facepalm moments, are not these? Well, listen. These are situations caused by software engineers like you and me. Why? Because many times we fail to apply common sense. We tend to ignore warnings. We bypass important processes. All because we are too confident of ourselves. Confidence bordering on megalomania. How can we the experienced be wrong, right? And the casualty is quality of the applications we created.

That brings us to the crux of this blog post. What would it take to build better quality software ?

In my opinion there are three human qualities that helps software engineers to build better software, and all three are non-technology factors.

[Alert: This may sound too philosophical for some.]

1. Humility​

Being humble is a virtue, and that we all know. Being humble also helps us to deliver quality. One reason we software engineers tend to overlook potential bugs and bypass processes is because of "we know how it works" attitude. One may be humble as a person, but if our know how about technology gets into our head, we will lose our humility when it comes to our work. We will refuse to unlearn and learn. Result, our deliverables will suffer on quality.

2. Patience​

Rushing through will not help. We need to ensure reasonable speed, and reasonable speed only. Any thing more than that will only increase the chance of we becoming careless. Whether it’s architecting a solution, or writing code, or testing, or deploying a solution, make sure we are at the right speed of execution. We should tick all the checklist items and never bypass processes. That time is well spent.

3. Logical reasoning​

Logical reasoning is a function of one’s ability to apply common sense at the right time. We need to be clear about the logic behind every action of ours, and should be able to explain why we did what we did. When following processes defined by someone else, make sure we understand what it’s about and why we are following that process. Everything that we do should have a logical reason. This clarity will help in ensuring quality in whatever we do.

Make no mistake, all the above three qualities sounds easy, but they are not. It requires much effort to imbibe these qualities and apply them in our work. But we need to. That will avoid facepalm moments for us and for our clients.

Your thoughts?