Avainsanat: ‘productivity’



You Can Take Too Much of Even Superfoods

25. Septemberta, 2014 | Kirjoittaja: Antti Niittyviita

My temples were under merciless pressure. Light cut my eyes and cold sweat broke. There was a sensation of vertigo from relentless headache and I felt like throwing up. I suffered a powerful migraine attack yesterday.

Luckily, I belong to the group of people who get better from a Burana tab and a little bit of coffee. Increasing the dosage of those two remedies makes me feel better faster and clearer, but how much is enough? If I take 5x800mg of Burana during the morning hours and five cups of coffee, then what?

Excess breeds nausea. Or gives a gastric ulcer.

Superfoods, pain killers, stimulants, alcohol, fitness, resting and even testing become detrimental when taken to extreme amounts. The benefit-graph stands true for pretty much all kinds of activity.

By increasing the effort, you gain more benefits… until the effort becomes excessive.

Optimal level is not discovered by guessing the dosage when one is already in a hurry. It is discovered by starting at once and regulating it more accurately with experience and learning.

Testaus 2010 Seminar Was Agile

17. Februaryta, 2014 | Kirjoittaja: Antti Niittyviita

I like seminars. One meets new people and the speeches usually manage to rouse lots of good ideas. I am writing about this, because last week I attended the Testaus 2010 seminar in Helsinki’s Tieturi. The event was definitely worth it and the speakers top of their line. In the event, they also chose the tester of the year Tero Jyrinki from Endero. Congratulations Tero for a job well done!

From the seminar programme’s presentations, most ideas were inspired by Logica’s Bob Verhoeff in his risk-based testing talk and Qentinel’s Katja Kuusikumpu’s presentation on choosing the metres for testing. These subjects will be talked about in the future issues of this blog. Order a feed right now!

But let’s cut to the chase. Again, there was a repeated case in the theme of the seminar about agile testing: “Are there shortcuts for agile testing?”, “Taking up agile testing and its phases”, “Agile testing in real life”. Agile is obviously trendy, you hear about it in every seminar. Agile is everywhere. Agile, agile, agile.

Phew. Despite agile, people usually want testing to produce solid yet believable data on the project. Like Katja in the seminar said, testing has to be able to produce accurate metrics on the project’s advancement, on the quality of the final result and even on money. How on earth can these subjects be measured extensively, if we remind ourselves about:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Doesn’t measuring stuff especially require at least good processes and functioning tools? Doesn’t measuring stuff require good documentation and on top of it a hint of organized planning? Quite a dilemma to investigate, I say. It is easy to talk about and easy to demand. And it does work sometimes.

Before the next project, one needs to state that STOP, take a breather and think:

Not everything goes into the same equation. If you demand real agility from your team, it happens in the expense of at least metrics.

When the Cat’s away, the Mice will Play

21. Decemberta, 2012 | Kirjoittaja: Antti Niittyviita

We at the Prove office have always had an unbelievable mountain of coffee cups on the kitchen table. We hauled them into the dishwasher each Friday while cursing loudly.

Why can’t you shove these where the sun won’t shine right after you’re done using them?!

Then came Jaakko. Jaakko had a strange habit. He always does more work than is required of him. And the results speak for themselves. The man solved our problem right away with a very simple threat.

“Don’t leave coffee cups lying around!”

“(or I’ll kill you!)”

From that point onward, the coffee cups could no longer be seen. Now we are facing strange times, since Jaakko is packing up his things and leaving after Christmas to Helsinki. He departs to strengthen up Prove’s team to the capital region for the duration of this spring. Will the mice play, now that the cat is away?!

Hardly, since this year we have again learned something important. These lessons also stay true outside the realm of testing.

It is worth doing a little bit extra work than what is necessary. When you have achieved the level of trust, no one is there to look over your shoulder. You even get more results and get to smile all day long.

Prove and the blog wishes everyone a wonderful Christmas!

Urgency, what a Wonderful Excuse

17. Decemberta, 2012 | Kirjoittaja: Antti Niittyviita

It is easy to hide behind urgency. Especially when the urgency is real. Urgency is an attractive excuse to postpone something unpleasant indefinitely. Who would actually want to know what the status of the software is, if that will just cause extra work?

No can do, we’re far too busy. Let’s test in, say… March.

Urgency can be caused by several factors in a software project. Pretty often the project risks are about lack of resources or running out of time.

  • It feels like deadline is upon us and that there are too many issues still
  • It feels like the pace of development is hurried and torn
  • It feels like there is not enough manpower in the project.
  • It feels like the marketing has promised the impossible

Projects often start steady and peacefully. Then the pace gets quicker and finally the urgency grabs a hold of you. The last weeks of the project are fueled by kebab, coffee and sleep deprivation. That if anything is healthy. In addition, it feels good to be able to brag to your friends about being busy.

These problems are most typical in projects where the testing has been taken care of amidst your own work. Testing is done when you have the time for it and sometimes you can skip testing. Urgency is a wonderful excuse.

As a matter of fact, neglected testing due to sense of urgency is the main reason for the urgency getting even more urgent. Controlling problem spots, emergency updates and warranty fixes make deadlines impossible to meet. And then, you run out of resources.

Sometimes you are so busy rowing that you do not have the time to start the boat’s motor. That is when it is a good time to roll up your sleeves and get out of your trenches. Stop hiding behind urgency!

Short but Sweet

26. Novemberta, 2012 | Kirjoittaja: Antti Niittyviita

I recently had a long discussion about the difficulty of specifying. In one firm, the specification phase gave them loads of trouble, since it seemed to drag on for very long times with each time. In worst cases, even years. As a result, the feature list of the software under development had pages upon pages of speculated material to go through.

No one felt like reading the specifications afterwards. Finally, even the implementation did not match them. The situation is actually quite typical in big software projects or in organizations who are set in their ways.

Steps to take in order to fix the situation is quite simple:

Decide first what is the maximum length of a document. Agree upon that each document is at most two A4-pages long. Then focus on crystallizing it.

Silence fell to the opposite side of the table. “You can actually do that?!”. I think you can. And should.

I easily produce pages upon pages of dragging on and useless drivel. If even for a moment you feel like doing the same, I recommend returning to Mark Twain’s words.

I apologize, since I had no time to write briefly.

Person’s Innate Laziness as a Trump Card

8. Novemberta, 2012 | Kirjoittaja: Antti Niittyviita

I admit. I can be pretty lazy sometimes. My opinions reflect that quite easily:

  1. Vacuum cleaning is pretty darn boring. Same areas one week after another.
  2. Washing the dishes is stifling. The cleaning agent dries the sensitive engineer fingers.
  3. When ploughing snow I get sweaty and get way too much fresh air. Not good for a nerd.
  4. It always makes me feel anxious to pay bills, even when doing it through a terminal.

When things get boring, my creativity blossoms. Suddenly, I start working hard to solve my problem. I get a robot vacuum cleaner, which takes care of about 90% of the boredom. Investing in a dish washer easens the workload by 85%. To plough snow, I borrow the neighbour’s snow blower if things get really hard. Paying bills gets 80% of them done automatically when using the web bank.

Automation really makes life easier. I use tools for the jobs that I do not feel like doing, or if I want to get them done faster. In kind of chores, which would not benefit me or my household any extra if done manually. The same principle holds true for software development or testing.

  • Do not automate, if manual work provides results and feels better.
  • Automate, if manual work is super boring and repetitive.

The pit fall of automation when someone estranged from manual work makes decisions regarding the direction the business of project is going. Then, the goal gets shifted from a operational end result towards functioning automation. Ultimately, the people will work towards the wrong end result.

People have a habit of finding ways to do less work. Trust in that innate laziness. Give your team free reins to choose their tools, so automation is sure to find their way to your place, too.

A Monologue Backlashes in Product Development

25. Septemberta, 2012 | Kirjoittaja: Antti Niittyviita

Last week we discussed a project that was already a month late from its schedule. Since money governs the businesses and testing has to be an investment, we decided to find out what was going on: We interviewed the project group.

Product development cycle in the business was 3 months in entirety and testing was emphasized in the end stretches of the cycle. After the interview we could state that the number of bugs found during the last stretches of the cycle had, like always, caught the software development by surprise. However, the number of bugs was not their greatest challenge. Fixing the problems just took a confusingly large number of time. Why was this?

Let us think about the situation where Calvin the Coder builds a new feature. The number of lines can easily number in hundreds. Then Calvin’s code from August-September reached the testing phase in October and bug reports start to emerge the fixing process can start. But what do you think? Can Calvin remember what kind of changes was done to the code in August?

Is it a wonder at all that digging through old lines of code can take so much time?

We stated that the same problem systematically plagued projects whose product development cycles were long and where testing was emphasized on the last stretches. First came the coding monologue, then came the testing. The product development was and stayed sticky. We figured out two possible solutions to the problem:

  1. Speed feedback cycle by forcing developers and testers to a dialogue
  2. Budget the project a plenty of time to fix things and hope for the best

You do not have to be a rocket surgeon to guess which option the product development lead chose.

Product development is always a team game. Quality includes staying in schedule. Only a fast dialogue between testing and development can guarantee fast results.

But it isn’t Worth in Investing in Schedule!

21. Septemberta, 2012 | Kirjoittaja: Antti Niittyviita

We dug our claws into a project, whose delivery day had been postponed by bugs found at the last minute for over a month already. Nothing new under the sun, we stated. This software development cycle had already been done for.

During the lunch break of the starting day we stopped to talk about money, like we have a habit of often doing.

When a project is delayed, what does it mean from the perspective of the project’s turnover or budget?

If the product development team takes 15 people’s full workload in a month, then a careful estimate would place the extra month of fixing bugs as costing dearly for their employer.

According to Palkkavertailu.com service, a software developer’s average salary is around 3600 euro. With the employer’s side expenses and holiday salary the entire expense comes to be around 5400 euro. A team of 15 people would therefore cost around 81000 euro in one month. (*)

The direct expense caused by a delayed project is rather high. The budget cannot hold and profit margins get swept even though the project could be a long one.

The delay costs not only money. The client can wait for the update with eager anticipation. The feeling of disappointment is pretty difficult to heal. In future, potential deals can be postponed, even remain entirely unborn. The resources allocation of the business gets disturbed, since the next project does not gain the people it was intended to get. In the end, even that project gets delayed. What we have then is a running start. Effects flood into my mind, when I stop to think about it for but a moment. Suddenly, a question springs into my mind.

How much would you be willing to invest for a project to remain in schedule?

(*) In reality, the expense is even greater when you consider work benefits, health care and tools!

A Finnish Man’s Problem

5. Juneta, 2012 | Kirjoittaja: Antti Niittyviita

A picture rail is a simple lath, which is installed just below the ceiling in a house. One can hang paintings onto this list to an adjustable height and place by making use of fishing line. You need not drill any holes into the walls, so switching the paintings and replacing them is nice and easy.

My picture rail has been gathering dust in my dress room for the last two years. During that time, I have moved a couple of times to a new apartment. Yet, that rail just hasn’t found itself in its intended place.

My trouble is something that is shared by pretty much all Finnish men.

I cannot get started, because I would have to first go to the hardware store. To by tools, that is. I would have to buy a ladder, screw wrench, special screws and worker pants, which could hold the tools while I climb up the ladder.

When you stop to think about the problem a bit more closely, the solution is evident. I could get up on the kitchen stool and screw in the rail manually. I bet the end result would be quite ok. It’s just so hard to get started.

I quickly remember employee Turkka Jalmanen’s words:

Tools and solutions come and go. The main thing is that you get results. Therefore, today is a good day to get started.

Tester Mushroom Gathering

23. Aprilta, 2012 | Kirjoittaja: Antti Niittyviita

The very delicious, yet poisonous, brain mushroom season is approaching fast. That means wandering around in sandy boreal forests. An experienced brain mushroom gatherer knows the best spots and can also intuitively discover new mushrooming grounds.

As the new season starts, Matt the Mushroomer yet again drives to the end of a familiar forest road and goes hiking with his backpack. The goal is to reach the nearby pond to grill sausages over open fire, just like always in the spring time. Matt wanders around in the boreal environment, trying to actively spot any brain mushrooms that might be found near his intended path. He finds some and the backpack is getting heavier and heavier as he reaches the open fire site near the pond. Matt is satisfied.

Matt’s day job is software testing. He decides to try out the new technique familiar from his workplace and writes down his exact path, step by step, in his map. When Matt has finished cleaning his haul and emptying them to a pot, he starts a new mushroom gathering trip. Could he find even more mushrooms if he were to retrace his steps?

It went just as one should expect. Matt notes at the open fire site. The mileage walked anew did not yield any results. Documenting the mushroom gathering took excessive amounts of time and the concrete results of walking the distance anew were scarce. Matt could only accept the self-evident truth. The best results are yielded when he chooses a different path with each trip.

The same holds true for software testing. New bugs and new information about the tested product is found in diminishing amounts with each testing cycle, when you equip the tester with racing horse’s blinds and make him tread the same path time after time.

If you have limited amount of time and money, you should focus on the essential. It is most important to detail the goal when planning the tests. That, which has to be tested. When the tester gets to choose his own path, it is certain that there will be more results.