This week is focused on science, observation, and investigation.
But not in the usual way, but in a different way to make other kinds of prototypes (pretotypes).
Also, is focused on the automation of some tasks, including automated testing.
Pretotyping
One of the main topics of software engineering is innovation, but innovate means investing a lot of time and money in the development.
That’s why you can see a lot of prototypes and market research, to realize if those ideas work.
But with pretotyping there is an easier way to handle if an idea works by making just the minimum, no development included, and even in a low window of time to get it done.
Pretotypig is the minimum of the minimum experimentation of an idea. One example is the IBM pretotype for text-to-speech technology.
They tell people to test their new computer with voice control when in reality a person was typing handily all what they are saying.
In the end, they realize that text-to-speech sounds like a great idea, but in reality, is too slow and that the people don’t really wanted it.
In this way, the company just experiment and realize that there was no point to invest in text-to-speech technology without writing a single line of code or prototype.
Your own black box
Learning from mistakes is easier said than done. I have talked about this in the past weeks but I learned a little more with an example of the aviation industry.
Every flight crash is properly investigated through the black box that is on the plane, is rare that an aviation accident is covered or not investigated.
Every time that a tragedy happened, they take the opportunity to learn how to prevent this to happen in the future.
We also need to have this mindset, not to cover our mistakes but investigate them, understand, and know the way to prevent that to happen again.
The art of explain
Most of the brilliant people that are out there or in the past have something in common.
They are not only recognized the knowledge that they have but their ability to transmit their knowledge to others.
More than being intelligent, they describe things in a singular way that anyone else can understand.
The way to archive is throwing true passion about the topics you are in.
Computing everything
One of the barriers to communication through computers and humans is the language.
Computers can handle a lot of information but search something specific can sometimes be trickier.
This is why exist some projects to answer questions with plain human language like Wolfram alpha.
Continuous integration
Continuous integration is a vital part of working on teams as developers.
It provides real-time information to build monitors, test all the builds and deploy safely the releases that the team makes.
In my short experience when you start a new project you may think that you don’t need continuous integration because “your project is too small for that” but with time things get bigger and bigger, and then you end with a lot of work that can be easily automated with continuous integration.
I don’t know how, but test it
Something that I learn when I see google conferences about testing is those big companies have real problems testing their products.
Tests take a big number of resources that easily escalate and increase with time but not because that they stop testing, they take other ways to validate their products.
Testing is one of the more vital steps in software development, I will apply this to my future projects because QA is not just a department, is a collective effort.
Chaos Engineering
This name is literal, chaos engineering is a technique of testing that makes some systems fail or intentionally shut down parts of the system in order to know how robust is the application and how it handles the errors.
This is an interesting technique that Netflix has an open-source project for called the chaos monkeys, where each monkey causes certain problems to the system to work correctly.
