Blog‎ > ‎

Software is Just Another Tool

posted Apr 13, 2015, 3:00 PM by Unknown user

This week we were assigned to conduct three experiments to solve three problems. This was to learn that software is not the solution to everything, but is just another tool used to solve the problems we face day to day. 

Some of the videos we watched this week were related to last weeks videos, since we saw some of the quantum machine videos, this week some were related. Several of them were on Feynman, a person who I didn't really know much about before. 

After watching the videos I have come to learn that Feynman was quite the character. He was a really cool person who made a lot of contributions to quantum physics and quantum computing. 

A part I really loved about the video was when he told a physicist (I forget the name) “I redid your calculations last night, and you're correct” and the guy was like “wait, what?! It took me six months! What do you mean you 'redid them last night'?” 

Although his lecture on the scientific method had very bad audio, I liked the way he teaches. It's true that he was a great explainer apparently. He seemed to teach with good humor and simple concepts. 

The videos by Seth Lloyd were a lot more techy, talking about quantum computing and “programming the universe”. What I learned from these videos is that the universe is infinitely more complex than we can ever fully understand as humans. I found the analogy of the universe itself is a computer in which it's elemental particles are making calculations and changing their state based on interaction. 

There was also testing subject, a video that talks about Netflix service. Big systems such as this one are hard to make without any flaws. So the system has to be tested exhaustively. 

I learned through this video that there is more to testing than just unit testing. There's several strategies to testing, like simian army, canary deployments, and a lot more. I think the important thing to testing is to always test before deployment. 

Each new feature or change should be tested, to avoid issues later on in users' homes. The video also talks about several issues that they've had to deal with. As in everything else, it's utterly important to not make the same mistake twice. If an issue is found in testing, it should only be found once, and fixed. 

The mentality shouldn't be “found an issue- report it” but “fixed an issue- moving to the next one” and that issue should not appear again. The problem is not finding bugs but fixing them. 

The problem then becomes the motivation in engineers, because a lot of them don't like testing. A suggestion would be to not just give them red boxes, but green boxes from time to time, to keep up morale. 

I also learned that when something fails, the ideal thing is to find the root cause of that fail. Have a culture of fixing problems in a way that the next time it breaks fixing it will be easier. 

Testing in bigger systems (like Google) are a lot more complex. Google actually built their own continuous build system where there could be simultaneous tests that didn't interfere with one another. They then have a matrix of changes and tests where you can identify the test, the change and where it broke. Ingenious. 

At first I thought that test engineering was the QA job, but my mentor explained the difference last week, and this week there was a video where they mentioned it. Test engineering is not QA, but has different roles. I have now a better understanding of test engineering, and testing in production, and testing during development, but am now slightly confused as to what QA actually does…