Arkisto: December 2016



Isaac Newton’s Christmas Land

24. Decemberta, 2016 | Kirjoittaja: Antti Niittyviita

I was planning Christmas shopping three months ago. I was planning the very same thing one month ago still. Finally, I made good on the plans in some three hours before the closing time. And I was not the only one up and about at that time. Most of the evening was spent waiting in queues and parking lots.

Christmas is a time of peace and quiet. Yet, yesterday I was presented with the opposite. Horrifying hurry and ruckus is what it was.

What often happens is that the peace and quiet is scary. That is what it is on holidays and in projects. We fill our time with lies of seductive speed, and if that’s not enough for us, we further boost the sensation by a pan full of coffee.

We do this even though it is apparent that the greatest insights of life emerge from the empty space known as silence.

Isaac Newton first had to sit under the apple tree.

Now that the Christmas is upon us, I bravely suggest the following experiment. What if you would put your earphones on and dedicate spending the next four minutes with Alan Watts? And even if you were an engineer, you could silence your thoughts and just concentrate on how it feels like?

Katri Helena and Juha Vainio composed a piece called Joulumaa some 40 years ago. If you happen across that classic today, I suggest you think of one question after Alan Watts. What does that piece really tell of?

Merry and peaceful Christmas, dear reader. We shall meet again next year.

The Most Important Purpose of a Contract

20. Decemberta, 2016 | Kirjoittaja: Antti Niittyviita

Last week our Jaakko was presented with a client’s working document. It was one page long and also practically served as a contract for the job.

I was left with a bone in my hand.

I, on the other hand, received another working document at the same time. It was 76 pages long with attachments. The end goals for either are not different. Only the client was.

I bet it does not take long to guess which of the jobs gets a faster start. It is quite plausible that in Jaakko’s project the first results are already presented by the time I have even finished with the document’s pages.

At times it feels like the most important purpose of negotiations has been forgotten in businesses. The purpose of negotiations is not to provide a contract, but to start the cooperation. Preferably while the results of the cooperation could still be said to be fresh and useful for all parties concerned.

If the most important result of a negotiation is cooperation, then what is the most important purpose of a contract?

The most important purpose of a contract is to pave the way back to the negotiation process.

A Deer in the Headlights

9. Decemberta, 2016 | Kirjoittaja: Antti Niittyviita

I was driving from Haaparanta to Oulu in the darkening evening. I have to admit that as a city-born person who has not driven many long distances in the dark my senses were wired up to the extreme. Someone could even say that I was tense.

While driving, I had a little thought experiment and suggest that you do the same. Imagine that you are driving a car. In the dark. No headlights. No street lights. No nothing. Just darkness. Afraid? No, you are not permitted to stop. You just need to keep on driving.

You know that you are driving and that the car is moving. You might even see how fast the car is going by looking at the speedometer, but you have no idea as to where you are. Not at least before you have crashed or driven into a ditch. Where are you going? Is there going to be a crossing? Are there going to be turns, or obstacles such as other cars, pedestrians, children, reindeer, moose etc. Should you lower the speed? Or turn the wheel?

Very few drive cars like that. They want to at least use the headlights, preferably even the high beams. Yet, many software projects drive in the misty night either completely dark, or with parking lights on, at the most they employ the headlights. I would call them foolhardy!

The mission of software testing is to provide information not only about the current state of affairs, but also of the dangers lurking ahead. The more different areas of testing you add to your software project, the more vital information you get. In your mind, are the headlights of your software project sufficient?

Of Birth and Prevention of Defects

7. Decemberta, 2016 | Kirjoittaja: Antti Niittyviita

Where do bugs come from? To most it is clear that bugs are born elsewhere than just on the keyboards of developers: A specs that falls short or is obsolete, misunderstandings between the client and the executor, unpredictable mismatches between different parts of the system are some examples.

But to great many of us it is a bit more difficult mind leap to make in order to understand that many defects have more than but one origin.

An inadequate specs is not the sole reason for why a feature gets coded wrong. The other possible reasons are hurry, due to which suspicious parts remain unverified, especially when the all-knowing oracle, the expert who knows everything about that part, is unable to be contacted the moment people wanted to get answers.

The final change before a bug emerges might be trivial, but when piled on top of all the other lines of code who work ‘almost right’ it might be the famous straw that breaks the camel’s back.

The autopsy of fixed bugs, also known as post mortem, can be an useful working method, when trying to figure out what parts of processes in the software development ought to be improved. Because the resources are limited, it is not possible or even feasible to try and fix every area. But if there is an area which repeatedly spawns bugs, then it is definitely worth investing in to take care of that area.

A person with human flaws is always a part of why a bug gets birthed. But the person is not solely to blame for it. Even when a single professional is involved with creating many bugs, the situation will not get solved by playing the guilty game.

That, which is needed is for that person to get help.

Slapping someone with a guilty card will only result in defence reactions and stress. Figuring out the complete picture and fixing the factors involved messages that even people are permitted to learn from their mistakes.

After receiving the right feedback people are a self-repairing system. This ultimately leads to the birthplace of bugs becoming more silent.

Looking for a Purpose

2. Decemberta, 2016 | Kirjoittaja: Antti Niittyviita

Nothing in this world is void of an use or of a purpose. A flower blooming towards the sky in the meadows is nothing more but a flower. It lives for its beauty, because it itself is beautiful. A river splitting the firmament does not experience itself to be useful nor useless, because it is merely a river. It need not be anything else.

A human has evolutionarily hardcoded special habit of trying to categorize the surrounding world in relation to itself into boxes of beneficial or detrimental.

That, which you categorize in relation to yourself more or less useful, does not necessarily match how the other people think about it. You value processes that produce software to your client in planned schedule too much. You are quick to judge practices, which have once permitted a defective software to enter production. When everything goes wrong you look for the guilty party and swear you will design the execution to encompass more next time. None of this matters a whit if you cannot understand those who think different.

Often, these people who think different include even your client!

Does the flower in the meadow have a planned schedule for blooming? Has it planned beforehand to pollenate its seed to increasingly wider areas? Does it avoid becoming fragile to the last, even though the last rays of the summer have already fallen beyond the horizon? By blindly following its own values the flower could never be successful.

By following your own values, never questioning them, you will never be successful. The condition for success is to question the past, and the factor that does the questioning is the testing, whose results give you the fast response for the work you have done. By reacting to fast response will you be at your best.

You have erred in thinking that the purpose of testing is to ensure that the software works within the allotted time. That is the purpose of checking. The purpose of testing is to question the plans you have drawn, and the work you have done for them. The purpose of testing is to question your values! Testing on its purest is a legion fighting for the values of your client, so that you can reform yourself for the better.

The values your client asks for is your lifeblood. The best you can do for your business is to open your eyes to see the world through your clients’. The eyes, through which a professional tester looks at the world.