Striving For Early Feedback

I’ve been for a while now at a new client. It’s been my second client while working as a consultant for my current employer (Comiq). When talking about challenges and the scale of testing problems, current project is on another level when comparing to previous ones. Luckily, there’s one thing that helps a lot. That’s the fact that we’ve jumped in couple months before the actual implementation (writing the code) starts. I could easily write a blog post of its own from being early in a project as a tester, but that’s not what I wanted to write today.

I wanted to write about early feedback.

Before we will go into that, let me open up the context a bit. Well, as much as I can while respecting the NDA.

Explaining the context

Wenjie Chang - Flickr

This project is one of those where one vendor is building a new solution that will have integrations to several existing systems. Those existing systems have their own vendors developing the integrations. The solution that we are interested of, is also only one piece of the puzzle for those other systems. They have all kinds of projects going on and many of them are related to things already in production. Production has usually higher priority when we are talking about urgent issues for our project.

You can probably figure out how the system architecture diagram looks like.

Yes.

Lots of boxes and arrows. And as usual, system architecture diagrams are not the reality.

Motivation for early feedback

Considering the challenging nature of this project, there’s one thing we have been trying to emphasize a lot. That’s early feedback.

I’ve noticed how there have been examples on this client where problems are being found quite late in development process. Also the amounts of problems being found are high. This has at least two possible problems in itself.

Firstly, fixing a lot of problems in a specific point in time, will raise the probability of regression and also slowdown the ongoing development process.

Secondly, problems can be more challenging to fix when there’s a long time between introducing a problem (e.g. coding mistake) and actually finding it. One developer I’ve discussed lately, compared this to cancer that is spreading slowly. Spreading cancer being a metaphor for accumulating code that is being built over the one that is causing problems to someone who matters. Good to remember also that there are though factors (e.g. design of the code) that affect to how easily problems can be fixed later.

How we are trying to provide early feedback

Being early in a project has given us the privilege to sit down with vendors before the implementation (writing code) has started. Basically we have explained the challenges that I mentioned above and then we have discussed how vendors could help us achieving a state where problems are found earlier & how we also want to help them.

As for now, there are few practical things that we hope will help us achieving state where problems are being found rather sooner than later.

  • Reviewing specifications
  • Being part of discussions where decisions are made (e.g. workshops where functionalities are explored)
  • Testing in development environments (instead of waiting the software being put into “upper” environments later)
  • Having vendors physically in same place when e.g. new integration is implemented to development environment. Sort of Shake&Bake that James Bach has referred to in a video where he explains how to test in an agile software development team (https://www.youtube.com/watch?v=vqwyMaHcjQE)

There are few challenges though, that I’d like to discuss about.

Challenges

https://flic.kr/p/9Mkydp

Perhaps the greatest challenge is visibility. Well, lack of it.

If we want to test functionalities early, that would mean that we know when they’re testable in specific environments. Developer could always contact you directly when there’s something to test. But, what if there’s something new several times a week, or a day? And there’s, let’s say 7 vendors? Instead of testing you’re spending your time answering your phone or reading your emails.

When I realized the visibility challenge, I first wanted to start from checking how different vendors are providing visibility to their colleagues. After that we can think about providing visibility to us.

I’ve discussed with several vendors and discussions have been promising. Each of them have had their own way of visualizing their work. Our objective is to be able to determine, based on those, when specific functionalities / features are testable at certain environments.

Other challenge is scheduling. By scheduling I mean that pieces of software are being dropped in such a way that we have realistic change of testing them early. If there’s several new features being implemented on a same day, it can lead to feedback loop growing yet again, because we can’t test all of them at once. At least not while having good coverage. Whatever good coverage means in this case.

Not there yet

As I’m writing this, the overall approach is still shaping and near future will tell how those challenges will get tackled. There will also definitely be some kind of “Lessons Learned” type of blog post of this project when there’s enough meat over the bones. Before we get there I’m planning to share how I’ve used modified Agile Testing Quadrants as a communication tool in this project.

 

Prioritizing My Time

Prime-Time-Clock-by-zoutedrop-Creative-CommonsWhile procrastinating my blog post about BBST Foundations course (I’ve been on two of them and will compare them), I thought I could write a bit about how I prioritize my time.

Big Rocks

We all have 24 hours to spend. Every day. The way we use those hours, varies a lot though. A while ago I was listening an Udemy course about time management and it had a part where the presenter filled a glass jar with big rocks and sand. Moral of the story was that we should fill our life with big rocks (things that are important) first and only after that with sand (which represents all the little things). You can find similar video if you just google “big rocks time”.

Big rocks of my life are mainly:

  • Time with family
  • Work
  • Sleep

I think it’s good to open up those a bit.

Time with family

I have a fiancee and 3 years old son. When I get home from work (basically 4pm always), I spend time with them until our son is sleeping. When I say I spend time with them, I truly mean that. I don’t watch TV, use my laptop or play with my phone. When you have 3 years old son, being mentally engaged is important. Same applies to fiancee also.

Exceptions are really rare. I mentioned BBST Foundations courses. All the time I spent on those courses, happened when I was either at work, or when our son was sleeping.

Work

With work I mean working 8 hours a day, 40 hours a week. That’s it. I’m quite strict about not doing overtime. Sometimes (like 2-3 times a month) I will be one hour longer at work, but those are rare.

We had a conversation about this last week on our Helsinki Software Development Lunches (we go have a lunch at Helsinki center and discuss about software development – anyone is free to join). There was a developer who said that he has also really strict about 40 hours per week rule. He said that he has been pushed on working overtime, but he has asked the underlying reason for something being really important and urgent. He continued that if there’s a life threatening situation or company is in bankrupt next day – then he can be flexible. How often this is the case though?

Sleep

I need at least 7 hours of sleep per night. This is something I take also quite seriously and plan my activities so that it will be possible to sleep this much. Usually on weekends I will sleep longer, but I feel that 7 hours is enough during the week.

The Little Things

Those big rocks are something that are essential part of my life and will be affected very rarely. Sure, there are situations where I’m not entirely with my family after work. I might be making food, going grocery store or other similar things that needs to be done. Fortunately my son can be part of many of those. Depending on his mood.

As much as I would like to develop myself as a tester, I don’t want to do that by affecting big rocks. This is one of the reasons why majority of my learning happens while I’m at work, driving to work, putting my son to sleep (which requires just physical presence) or at the evening when I have a bit of my own time. I can’t even remember how many videos I’ve listened while driving to work. Videos from BBST to Oredev, Eurostar to TED Talks and Udemy courses to all kinds of Youtube talks. When I put my son to sleep I often read books. A while ago I read Jerry Weinberg’s ‘The Secrets of Consulting’ and ‘Are Your Lights On’.

It’s Not The Distance That Kills

I’ve seen several close people overworking and paying the price for it. Some are not here anymore and others, well there’s not much left of them. I’m also hearing these kind of stories while working and thinking that I’m not going to walk those paths. Because of these reasons, I’m strict about keeping the work hours on a level that will not affect negatively the whole. Work is only one part of the whole. Even though I love what I do and aim to become extremely good at it.

How about you? What are your big rocks?

 

Project Mercury and Death of Testing

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

I’ve witnessed lately few great blog posts about the role of a tester and where we are going with what we understand as testing.

First Alan Page wrote his post “Death and Testing“. Then Trish Khoo delivered her thoughts in “Forget developers in test, we need testers in development“.

I’d like to share my thoughts about this subject also. That being, where should we be as testers?

Project Mercury

Project_Mercury_-_U.S.Man_in_space

When we’re talking about challenging software development projects, I think putting the first (hu)man on space is pretty high on that list. Project Mercury had this as a goal on the early 1960′s when US and Soviet Union had their space race going on. Jerry Weinberg, among others, had to develop software that would help in taking the astronauts to space and back, alive.

Jerry talked about Project Mercury on This Week in Software Testing podcast, 2010. I totally recommend listening it, as it’s one of the best podcasts I’ve heard (even though you need to register to softwaretestpro.com). I took the liberty and wrote a part of the podcast, especially the part where Jerry talks about Project Mercury:

Because of the complexity and worldwide nature of the system. I (Jerry) decided that we need to have a group of people dedicated to quality, including testing of the system. We created such a group, which is as far as I know, had never been done before.  They lived through the whole project, unlike a lot of testing groups today. They were involved right from the very beginning. So, for example they could comment on whether the software we were building, was in fact testable, by then. Which wasn’t sure at all to just automatically happen.

Because this was, not only first human life system, but it was the first worldwide online system, ever build, and presented many unique problems in testing. That’s how we got into this. It was after that that other people began to realize they needed separate testing groups. But it became different. Our testing group was composed of experienced and talented software developers.

Later on, managers began to see testing groups as a way to hire cheaper people and put them in testing, because they didn’t have to know how to develop software. I’m thinking a lot of managers thought all they needed to do is sit in there on terminal and bang on keys, like monkeys. Of course that’s simply not true, but it’s taken us a long time, for many people in industry to realize, that testing is as professional, a job, as we realized it back, literally half a century ago. And many managers today still don’t understand that.

In early 1960′s testing wasn’t yet defined, which meant that Jerry, and others, were not growing up with the same dogmas as we do these days. They didn’t have the mental (or concrete) walls that tend to separate testers from development teams these days. They just tried to come up with a good solution for the challenging problems they were facing. Therefore it was natural for them that few of the team would be putting more focus on testing than the others. Also, it was similarly natural that they were there since the beginning of the project and equally part of the team, as the others.

The fact that they were skillful developers is NOT the point. The fact that they were able to be valuable for their team, IS the point.

Boulding’s Backward Basis

I heard Jerry talking about Project Mercury in the podcast, roughly year ago. That moment was one of the first that led me to learning about Boulding’s Backward Basis (didn’t knew about the name then). When people talk about testers these days, many of them mean people who are working on a separate team or otherwise separated from the development team. Personally I think these people are growing up with dogma.

If you think of it, software development as it is, including testing, is not something that it’s MEANT to be. It’s though something that it’s TURNED OUT to be. Now would be actually a good time to mention Boulding’s Backward Basis (from ‘The Secrets of Consulting’ by Jerry Weinberg):

Things are the way they are because they got that way.

I’ll admit that I’ve not dig deep enough the history of our craft, so I could connect the dots and say what lead to where (besides what Jerry is explaining above). I do know though that the idea about testers being separated from the rest of the team wasn’t common long ago and it is these days. Some people talk about future and evolving, but I think we’re going back to our roots and that’s a good thing.

One dogma to another (and beyond)

I understand testing as a mental activity of questioning, observing, evaluating and in the end, exploring. This will never go away. I hope.

I don’t know if testers being integrated part of the software development team is how it should be. It does sound reasonable for me in the contexts I’ve been. Though, it would be naive to think that this is how it’s MEANT to be. We would just be jumping to a dogma after leaving another.

Keeping in mind that we don’t know what we’re doing (see Future of Programming by Bret Victor), and at the same time putting effort on exceeding our limits. Maybe that will move us toward something better.

Learning From Our Mistakes

Mistakes are often seen as a fruitful way of learning. If you do a Google search for “Learning from our mistakes” – you will get a lot of hits. Quotations, articles, TED talks, blog posts, books, references to Bible and of course… Oprah.

I also thought for a long time that there’s nothing special about learning from our mistakes. We make them, learn from them and don’t repeat them. So what?

Then I saw this talk by Kevlin Henney couple months ago. (The failure part starts around 17:30)

Kevlin referenced to Henry Petroski’s “To Engineer Is Human” book on his talk. Based on this book, he talked about overgeneralization and context of a failure.

Let’s say we make a mistake, learn from it and aim at not making it again. Now, this might lead to the overgeneralization problem.

We should be careful to get out of an experience only the wisdom that is in it – and stop there; lest we be like the cat that sits down on a hot stove lid. She will never sit on a hot stove lid again – and that is well; but also she will never sit down on a cold one anymore. (Mark Twain)

This was something I discussed briefly with Seriouspony (Kathy Sierra) on Twitter:

Kevlin also argued on his talk that:

When we learn from our mistakes, it’s highly contextual. We learn from our successes far better.

By mentioning the contextuality, he meant that our failures need to be happening in a context of successes. Then specific failures can be noticed. There are examples of this on the talk if you’re more interested.

Learning better from our successes?

Kevlin mentioned earlier that “We learn from our successes far better.” What did he mean?

First of all, he was referring to a study (by Earl Miller, Mark Histed & Anitha Pasupathy) which said (https://web.archive.org/web/20091222020319/http://www.asfct.org/documents/journal/2009-11/Vol1-2-9.pdf):

The assertion that we can learn something from every failure is often heard. This study by Earl Miller and his colleagues Mark Histed and Anitha Pasupathy of the Massa- chusetts Institute of Technology’s Picower Institute for Learning and Memory tests that notion by looking at the learning process at the level of neurons.

The study shows how brains learn more effectively from success than from failure. The researchers created a unique snapshot of the learning process that shows how single cells change their responses in real time as a result of information about what is the right action and what is the wrong one.

Brain cells keep track of whether recent behaviours were successful or not. When a certain behaviour was successful, cells became more finely tuned to what the animal was learning. After a failure, there was little or no change in the brain – nor was there any improvement in behaviour. This research seems to support SF’s assumption that analysing why something went wrong is unlikely to lead to ideas about how to create a better situation.

I found an article by MIT News (http://web.mit.edu/newsoffice/2009/successes-0729.html) that opened up the findings of the study much more. You might want to check that out if you’re more interested about this.

Despite the credibility of the study, it’s an interesting idea though. That we would learn better from our successes?

While ago I tweeted:

John Stevenson replied to my tweet:

Cognitive dissonance is a good point as it will help as in noticing when there’s a mismatch between what we have done and how it perhaps should have done, in our opinion.

Mistakes are though a matter of perspective. You’re applying some kind of oracle to the behavior or act that you call a mistake. Can you trust your oracle? Same of course applies to successes. Not being a mistake is also a matter of perspective.

Wrapping up my thoughts

This whole “learning from mistakes and successes” is still an ongoing process. I haven’t came up to any solutions, conclusions or deep realizations about it. But there are thoughts that I’m playing with at the moment:

  • In order to learn from failures, they need to be buried among successes. Being the odd ones that are spotted.
  • If we truly are learning better by doing something we consider successful, then making a mistake, should lead to changing the behavior to something we consider successful and will also prevent making the mistake again.
  • Are you sure that the mistake you made, isn’t something that is a mistake only in a specific and unique context?
  • While there needs to be thinking behind mistakes (why did it happen), there needs to be thinking also behind successes (why did it happen).

This is a subject that I’ve thought about here and there for a couple of months now. Hope it will give you something to think about.

The Exploration of The Deep

TheDeep

I haven’t blogged for a while and main reason for that has been Claire Nouvian’s book: “The Deep”. The book contained one specific article by Dr. Cindy Lee Van Dover that led me to studying a lot more about deep-sea exploration. That article was called “The Exploration of The Deep”.

Earth’s Largest Living Realm

I knew basically nothing about deep-sea exploration before I started reading Claire Nouvian’s book. Now when I’ve spent time reading it, I realize that oceanographers are our modern-day explorers.

The difference between today’s adventures and those undertaken by Columbus or Livingstone lies in the equipment: submersibles and remote-controlled robots have replaced caravels and slide rules. (Claire Nouvian)

Especially the ones focusing on the depths of our oceans, are often the first ones to visit those places. Interesting fact is that there has been more people on Moon than on the deepest known place of our oceans. According to Wikipedia, there have been 12 men on the Moon. On the other hand there have been 3 people (Jacques Piccard, Don Walsh, James Cameron) on the Challenger Deep, in Mariana Trench.

At 150 m depth, 99% of sunlight has been absorbed by water. Below 1000 m, it’s total, inky blackness for all.

The deep sea was long considered as a lifeless world. British naturalist Edward Forbes declared in 1858, that life could not exist below 300 fathoms (~550 m). This statement was later discredited by Sir Charles Wyville Thomson, who was, according to Wikipedia, chief scientist on Challenger expedition. Challenger expedition laid the foundation to oceanography. Dr. Cindy Lee Van Dover described Thomson’s expeditions on the book.

Over four years, Thomson and his colleagues scraped the seafloor with trawls and dredges at depths of up to nearly five miles and recovered more than 4000 new species of marine life. The dredged-up animals were often mangled almost beyond recognition, but they were nevertheless precious specimens that revealed hitherto untold tales about the rich diversity of deep-sea fauna.

There were limits to what could be inferred from these samples; they often provided little insight into the way life on the seafloor looked, or into how the animals might interact with one another. To paraphrase explorer and humanist Théodore Monod, attempting to understand life in the deep sea using dredges is like aliens trying to understand life on Earth by blindly dangling a hook from space and retrieving a cockroach, a t-shirt, and an iPod.

Trawls and dredges allow us to measure the biological diversity found in the deep sea — they are still used today for species counts and other statistics — but they are almost useless for understanding animal behavior in natural settings. To achieve this goal, one needs to observe organisms in their environment. (Dr. Cindy Lee Van Dover)

Current estimates about the number of species yet to be discovered from deep sea vary between 10 and 30 million. On the other hand, number of known species populating the planet today, whether terrestrial, aerial, or marine, is estimated at about 1.4 million. This explains why deep sea truly is Earth’s largest living realm.

Crossota sp., a deep red medusa found just off the bottom of the deep sea. Image courtesy of Kevin Raskoff, California State University, Monterey Bay.

Crossota sp., a deep red medusa found just off the bottom of the deep sea. Image courtesy of Kevin Raskoff, California State University, Monterey Bay. Via Flickr, Creative Commons License.

If someone is thinking now what deep sea actually means, according to Wikipedia it is the layer that is on the depth of 1800 m or more.

I mentioned earlier that below 1000 m there is total, inky blackness. This is true and also far from reality. Reason for it being far from reality is bioluminescence. Dr. Edith Widder wrote on the book about bioluminescence.

There are only a few creatures on land that can make light. Fireflies and glowworms are some of the best-known examples, but there are a handful of others such as some earthworms, click beetles, snails, centipedes, and fungi. These, however, are relatively rare and they do not play a significant role in the balance of nature.

By contrast, in the oceans there are so many animals that make light that there are vast regions where as many as 80 to 90% of the animals collected in the nets are bioluminescent. In the ocean bioluminescence is the rule rather than the exception.

Bioluminescence occurs in all the world’s oceans from surface to bottom and from coast to coast. Appreciating how animals use their lights is important to understanding this ecosystem that represents more than 99% of our biosphere. Various light-producing chemicals extracted from different animals have also proved enormously valuable in medical and genetic research. Living lights in the ocean are beautiful, mysterious, useful to humans, and absolutely essential to the animals that possess them. (Dr. Edith Widder)

Photo by NOAA's National Ocean Service via Flickr, Creative Commons License.

Photo by NOAA’s National Ocean Service via Flickr, Creative Commons License.

Majority of deep-sea animals create their own light and that makes bioluminescence the most widely used mode of communication on the planet. Théodore Monod described this (bioluminescent) masterfully on the book.

Two things used to leave Kant awestruck: the star-studded sky above him and the morality within man’s heart. Had our philosopher taken a dive in a bathyscaphe, he no doubt would have added a third ‘wonder to the world’ to his short list: the fairy-like ballet of bioluminescent sparks that dot the abyssal night. (Théodore Monod)

Tools for Exploration

Because of the challenging conditions of deep sea, it took long before first explorers descended into the unvisited depths. In year 1934, deep sea pioneers William Beebe and Otis Barton, reached the depth of 923 m (according to Wikipedia). 26 years later, as mentioned earlier, Jacques Piccard and Don Walsh became the first to explore Challenger Deep, in the Mariana Trench. 0855409They went there with Trieste, bathyscaphe designed by the Swiss professor Auguste Piccard (Jacques’s father). Trieste was a sort of deep-sea elevator that could go up and down, but not horizontally. This limited a lot its ability to explore in the depths. Nevertheless, it was first piece of technology that enabled us to reach the deepest known place on our planet.

The ALVIN submersible begins its descent to the bottom. 2006 May 21.
Photographer: Gavin Eppard, WHOI.
Credit: Expedition to the Deep Slope/NOAA/OER.

Trieste inspired others to invent more sophisticated submersibles. Examples of these are AlvinArchimède and Nautile. Submersibles like Alvin, could move freely on the ocean instead of bathyscaphes, which extended our ability to explore the deep sea. Alvin can dive to 4500 m currently, but there are plans to increase the maximum operating depth to approximately 6500 m.

According to National Oceanic and Atmospheric Administration (NOAA), Alvin can remain submerged for 10 hours under normal conditions, although its life support system will allow the sub and its occupants to remain underwater for 72 hours.

10 or 72 hours may sound like a lot, but when you consider the 2 hours that it takes from Alvin to dive to its maximum depth, and another two hours back. You realize that large portion of its time is spent on going up and down. Also, according to NOAA, Alvin and Atlantis (the ship) costs $30.000 per day, which makes it an expensive option. Because of these and few other reasons, many scientists use ROVs (Remotely Operated Vehicles) and lately AUVs (Autonomous Underwater Vehicles).

ROVs can remain submerged several days because of the cable powering them from the surface. They provide visibility for explorers by transmitting video in real time. You can also take samples with mechanical arms. One of the most famous ROVs is probably Kaikō, built by the Japan Agency for Marine-Earth Science and Technology (JAMSTEC) for exploration of the deep sea. Kaiko was the second vessel that dived into Challenger Deep, since Piccard and Walsh went there on 1960. Unfortunately, Kaiko was lost at sea on 2003.

U.S. Navy photo by Mr. John F. Williams (RELEASED). Via Flickr Creative Commons Search.

U.S. Navy photo by Mr. John F. Williams (RELEASED). Via Flickr Creative Commons Search.

Despite the usefulness of ROVs, there are though disadvantages and perhaps the biggest one is the cable that is required for operating the vehicle. Partly because of this AUVs (Autonomous Underwater Vehicle) have been, and are being, developed. These could give us the freedom that ROVs lack of. There’s still though long way to go until AUVs replace ROVs on exploring the ocean.

Dr. Cindy Lee Van Dover wrote about the usage of technology on the book. This quotation was one of the primary reasons why I became interested of deep-sea exploration.

Since the discovery of hydrothermal vents in 1977, the pace of exploration in the deep sea has steadily increased, fueled by the finding of novel adaptations to extreme environments and by the gain of fundamental insights into how our planet works.

Our increasing ability to access the seafloor with new tools and sensors promotes and enhances exploratory activities. Tethered and untethered robots are now the tools of choice for many of the challenges faced by deep-sea explorers.

Nevertheless, the construction of two new human-occupied submersibles, one Chinese and the other American, underscores the anticipated need for a human presence on the seafloor for the next half century. (Dr. Cindy Lee Van Dover)

Current technology promotes and enhances our exploratory activities. This is the reason why technological advances are crucial for deep-sea exploration. It’s good to though remember that even though our exploratory activities are performed with the help of technology, we as a humans are still the ones that decide what to explore and how to interpret the data gained from our explorations.

I actually sent an email to Cindy Lee Van Dover, where I asked about the “anticipated need for a human presence on the seafloor”. I wanted to know more about the benefits of us being down there on the submersible instead of ROVs and AUVs.  She hasn’t replied yet.

National Oceanic and Atmospheric Administration (NOAA) – Ocean Explorer

When I started searching more information about deep-sea exploration, I quickly found National Oceanic and Atmospheric Administration’s (NOAA) Ocean Explorer website. The website is dedicated for providing information on NOAA’s ocean exploration activities, especially those being undertaken via funding from the NOAA Office of Ocean Exploration and Research.

It’s amazing how much information you can find from specific explorations. There’s mission plan, science objectives, mission log, photos, videos and introductions of people who are participating the explorations. All these create an interesting story about the explorations for people like me. What thrilled me the most though, was Ask an Explorer section. This gave you the chance of sending an email to Melissa Ryan, who would forward it to explorers. I just had to try this and was highly satisfied with it. I received thoughtful answer in few days.

Question fromAleksis, Finland
You seem to gather a lot of information with technical equipment (data, images, video). How about traditional note taking? Is there a need for taking notes with either pen and paper, or perhaps a laptop? If yes, what kind of notes?

Answer from:Brendan Roark, Assistant Professor, Texas A&M University
Yes, we take other types of notes. For example I take notes on my laptop of our position, what the bottom looks like, what organisms are present, technical problems and other important events like the first sighting of a coral during the dive or cruise. We use these notes to write our dive summaries. I also take pen and paper notes on a printed version of our dive map to help me keep track of where we have been.

There is also the IM chat room that logs all of the notes all the scientists make. We use all these notes and data, both the data, images, video and transitional notes to do our daily dive reports and web summaries. We also have pre and post dive meetings via conference phone to discuss and plan past and future dives, so that is also a more traditional form of communication.

I recommend that you explore NOAA Ocean Explorer’s website, if you’re interested any of the things I’ve written so far. For that matter, you might also want to check out their Youtube channel which contains many fascinating videos.

Space: the final frontier… Or is it?

When I was perhaps 12 or 13 years old, I used to investigate the craters of Moon with my telescope. Whole space was that large, mainly unexplored, territory that fascinated my mind. I watched movies of astronauts and read books about our Solar System. Needless to say, Star Trek was natural continuum for all those already mentioned.

Now, 18 or 19 years later, I’m genuinely surprised that we know so little about our oceans. More importantly, many of us don’t know that we know so little about them. There are millions of species to be found from our oceans and many of those can teach us valuable things in research (e.g. medical and genetic).

Lately the focus has been calibrated more toward the deepest places of our oceans. News about race to the bottom of the ocean support this. One can think about the motives of the people involved with missions like this, but it reminds people about the ocean and how little we know about it.

Cindy Lee Van Dover started her career on the year (1982) that I came to this world. Among many other achievements she was a pilot-in-command of 48 dives with submersible Alvin. She was the main reason for me ending up writing this blog post and studying about deep-sea exploration. It is appropriate that I’ll end this post to her words.

Man has observed less than 1% of the seafloor; the challenge lies before us. During the twentieth century, the deep sea became accessible. In this twenty-first century, the deep sea will become known. (Dr. Cindy Lee Van Dover)

Audio Of Several Let’s Test Sessions Shared

Me and my colleague (Samuli Elomaa@samuliel) recorded a lot of sessions, and keynotes on Let’s Test conference. In total we recorded 11 sessions and 2 keynotes. We recorded them mainly for two reasons.

  1. We wanted to share the recordings with testing community
  2. We wanted to have more material to support our notes

After listening the recordings, we had to drop few. Kristoffer Nordström’s python coding session was not really that helpful, without you seeing what’s happening, when he is coding. Then there were few sessions, that I’ve not yet received permissions for sharing. I’ll add them later if I receive permissions. It’s also good to know, that we cut the conversations with pairs from Tobias Fors’s Systems Thinking For The Rest Of Us. You couldn’t understand the conversation, so we concluded that it’s best to cut it off. Tobias knows about this.

So, in total we are now sharing 8 sessions and 2 keynotes. Regarding keynotes, you can already find the audio from Johanna Rothman’s keynote, here. I will though share that audio file here also. It’s also good to know, that Ilari Henrik Aegerter has already published the video of his talk here. We still thought, that someone might find value in the audio of his talk, and therefore will publish it here also.

My colleague already shared these recordings earlier. If you want to listen them online, you can find them here (downloading requires registration, that is free).

Otherwise, here is the link that leads to a folder that contains the audio of those 8 sessions and 2 keynotes. They are at my Dropbox, where they are easy to download from.

https://www.dropbox.com/sh/hts8a69za2r6nco/1EcmTWP9c7?m

I also want to highlight, that I’ve asked a permission for sharing, from all of the presenters. If there is though someone, who feels that we should not share a particular audio recording. Please contact me, either here, or in Twitter (@al3ksis).

In case you want to record yourself in future. Here are few lessons learned, and details about how we recorded:

  • Both of us had Galaxy Note and Smart Voice Recorder application
  • We learned, that when sitting in the front row, you get better audio quality. For example, Zeger van Hese’s, Mark Micallef’s and Dawn Haynes’s sessions are recorded, when I sat in the front row.
  • Ask the permission for recording, before the session starts.
  • Ask the permission for sharing the audio after the session! (It has took a lot of time to individually ask the permissions afterwards)
  • If you take pictures, or tweet with your phone, don’t block the microphone. This is the reason why sometimes the voice is a bit muted in our recordings.