Tired of Answers

Complaining, Software Testing

During the past few years, I’ve interacted with many experts, thought leaders and emerging talent and boy, there’s plenty of them. I mean this in a non-comical way, there is tons of talent, keep your eyes open and ears cleaned (this was meant comically).

Regardless of where I am in the food chain of conference goers I can’t help but observe, learn and… among other feelings; get frustrated.
The thing that has been baffling me for the longest time is that people come to conferences, fora, slacks and: ask questions. That’s not the crazy part. This is:

People expect simple answers and crazier yet, they get them.

Here’s why that’s preposterous: You are working in a complex situation. Everything is subject to change. Nothing is certain to be static. Assuming it will be, is risky.
That’s the only given we have.

But how many people deal with that given, feels so very wrong.

We cut the problem into many smaller ones. We like that. It’s easier to understand. Less brain intensive, more straightforward to plan for and very manageable.
It’s a common engineering pattern. Imagine you’re on the team tasked with building the Golden Gate bridge? You look at designs of other bridges, work out how many bolts, nuts and bars you need and get setting them together.
That sounds easy, right? Except that something in the back of your mind is telling you it probably isn’t. Nobody has built a bridge of this magnitude before. This task might be more complicated than initially thought…

On top of that add the the following parameters:

  • The water it crosses is not a river, but a bay. Subject to the tides and rapid weather changes.
  • The political and territorial landscape might change.
  • Vehicles crossing the bridge will inevitably evolve, maybe even much sooner than anticipated.

Compared to other bridges, this one is proving to be a complex beast. As soon as we take the holistic view, we realise how wrong we were.


Here’s a secret. We’re all building complex beasts. We don’t understand the fundamentals, we can’t foresee the future, we don’t know our present well enough and we have no idea which parameters will change our situation today, tomorrow or just after the next major release.

Therefore I would advise everyone to quit looking for simple answers. They are false.
Therefore I would advise everyone to quit giving simple answers. You are not helping.

 

There are principles, models, sets of guiding rules, methodologies, approaches, tactics, heuristics, practices,… and many different ideas to help you do a better job.

Some of these can help you greatly, most of them were created and defined with good intentions but ALL of them have been misunderstood and/or misused by malicious or irresponsible actors. (including myself, at times)

The next time you’re faced with the need of giving or receiving simple, easy answers, repress that urge. Instead try to trigger thinking. Within yourself and within others. Thinking deeper, broader and in different directions. Offer alternative ways of thinking, provide helpful information and ask questions that may lead down a path.
The path of learning.

img_20171126_125504.jpg

 

4 thoughts on “Tired of Answers

  1. I enjoyed this article. I made a similar argument last night in a discussion on LinkedIn. Not in exactly the same eloquent manner though. I have been speaking to a number of companies lately and they all seem to be asking how to solve XYZ problem. Software development has become a bit more complex in the last couple of years with so many changing and emerging technologies it is hard to keep up.

    Architects and developers are adopting the latest and greatest designs and frameworks coming from leading companies like Netflix, Google, Amazon, FB, etc. and companies struggle to understand them properly to fully implement and test these solutions.

    The standard model of transition from manual to automated testing is difficult. Just hiring a few automation engineers isn’t enough to solve the problem because most automation engineers only know what they did or were taught in their last role. Usually with a totally different technology stack and solution (different product why).

    Understanding the entire complexity of the solution is so important. Understanding there is no simple singular way of approaching quality or even development for that matter is equally important. Understanding the choices made in the solution may require resources with different backgrounds or at the very least willing to learn new approaches.

    Liked by 1 person

    1. Thank you Doug! Keep up the good work! 🙂
      Nothing is as simple as it seems at first glance. Assuming that it is is very risky and will frustrate your co-workers (as a bare minimum).
      We need to start thinking more and not give in to giving and internalising information in a lazy way. If only that wasn’t so very hard…

      Like

Leave a comment