It was actually Scott Barber’s tutorial description that got me to sign up:

Context Appropriate Performance Testing, from Simple to Rocket Science

When most people think of performance testing, they think about the hard parts – the very hard parts. They think about the expensive and complicated tools that are required to simulate the activity of thousands of end-users all at the same time, while collecting tens or hundreds of thousands of measurements.

In reality, many performance issues can be detected and diagnosed with exactly the tools and knowledge you already have at your disposal using information obtained from quick, easy and cheap performance tests

I’ve worked at several different companies over the years, and performance testing is always one of the more difficult parts that is usually left to the end of the project. Performance testing steps into the lime-light when production crashes, or customers complain. Sometimes developers start worrying once all the functional requirements have been met and the product is ready to ship: “will the system stand up to real users”? Most often we think of performance too late, and as Scott said the solutions we think of the the “hard parts”: We need to reproduce the production environment exactly, we need to reproduce the exact load, we need to reproduce the system interactions exactly, and we need a tool to help us sift through all the data. Well, that’s pretty insurmountable a week away from release, or when production has already crashed.

I really wanted to learn how to get from “it’s impossible to performance test” to “we’re performance testing!” Even though the tutorial description promised that I would learn how to do that, I wasn’t too confident that it could be achieved in one day. I’m glad to say I was wrong! What a great tutorial. You can find the entire presentation here, but the biggest takeaway for me was the “Simple items”:

Kanske inget revolutionerande i sig, men för vissa kan det kanske finnas något litet nytänkande eller till och med provocerande i det. Kan det kanske inte uppfattas som oseriös, naivt eller dåligt? Eller om man är mer optimistiskt lagd kanske modig, eller orädd eller till och med lite dum? Att man är öppen för nya saker innebär ofta att man lär sig något och får nya referenser. Och ju mer man vågar prova på den spännande o-vissa vägen – desto mer lär man sig ju, och desto roligare blir det.

Visst är det självklart roligt när man känner att man kan bemästra något nästan till perfektion också. Självklart, det tycker nog alla. Men om det är målet, så måste man bredda sig när man har nått dit. Annars blir det för mig i alla fall riktigt jättelångtråkigt.

Inse att ingen kan allt

Jag har under de senaste åren träffat massor av nytt folk och gjort massor av saker jag inte har gjort förut. Vilket är fantastiskt roligt, spännande och lärorikt. Jag har testat, lyssnat, sökt stöd, frågat, delat med mig av mina kunskaper och erfarenheter. Mycket har gått väldigt bra, men vissa saker har jag kanske insett att jag inte vill göra. Många människor är nog som jag, och gillar att det är lite utmanande och lärorikt. Det går ju alltid bra tillslut ändå – eller hur? Men jag har inte bara en gång utan flera gånger stött på det där som är så vanligt hos oss tjejer (kanske hos killar också?) – Men jag kan ju inte det här till perfektion, så därför säger jag att jag inte kan det alls. Men HUR ska du då någonsin lära dig något nytt frågar jag så klart. Hmmm, ja, gå en kurs kanske, eller kanske fortsätta som det är nu bara? Jovars, det kan man ju hålla på med i all oändlighet i så fall. Du behöver troligtvis ingen kurs och du vill gå vidare. Du behöver kanske bara göra som vi andra gör och inse att INGEN KAN ALLT, och i stället säga att jag gör det där nu som jag inte riktigt kan och så lär jag mig det. Vad kul!

Kanske har jag lyckats sprida min optimism lite på vägen. Jag höll ju faktiskt en kurs alldeles nyligen, och fick där feedbacken att jag var så “härlig” för att jag sa att “Ingen kan allt till kursdeltagarna”. Jo, några frön sådde jag nog i alla fall och det känns riktigt härligt. Hur underbar skulle inte världen vara om vi var fler som vågade göra det vi ville och inte var rädda att bli tittade snett på eller rädda för att kanske, kanske eventuellt misslyckas?

En film från min kurs i “Attraktiv digital design” som inte alls handlade om design utan om olika sätt att utforska användarnas mål och ifrågasätta sin design. Att våga testa nya metoder, ifrågasätta det invanda och förstå att perfektion inte alltid är av godo – var några av grundstenarna i kursen.

Vad är det värsta som kan hända – och vad är det bästa

Jag kan också bli rädd, annars är man ju inte människa. Men det som brukar fungera för mig då är att fundera lite över detta – Vad är det absolut VÄRSTA som skulle kunna hända? Oftast så kommer jag fram till att det är skitfåniga saker som inte gör mig något alls egentligen. Och vad är det BÄSTA som akn hända om jag gör det här? Ofta en massa ny kunskap, nya kontakter – och mindre rädsla nästa gång. Fantastiska uppsidor!

En riktigt lång lista

Om man skulle ge sig på att försöka göra en lista med sånt som man har gjort som verkade halvt galet till att börja med, men sen visade sig leda till något superbra. Så skulle det för min del bli oändligt lång – men en ganska lärorik sådan. Till exempel att flytta till USA när jag var 17 för att plugga fotografi lite till, efter att ha pluggat redan 4 år i Sverige. Det gick åt skogen så klart, för alla pengar tog slut, jag längtade hem och allt blev tråkigt. Ett stort misslyckande kanske – jag skulle ju bli nästa Ansel Adams (eller nått). Men jag var faktiskt glad över allt jag hade fått uppleva och lärt mig. Att jag INTE ville hålla på med fotografi, att jag VILLE bo hemma i Stockholm – och att det var det nya svarta INTERAKTIVA MEDIER jag ville hålla på med. Jättebra! Jag ska nog sluta där tror jag… för den här bloggsidan skulle faktiskt aldrig ta slut annars. Men jag hoppas och jag brinner för att få fler att våga testa och misslyckas, våga fråga och lära sig mer av det som gör oss nyfikna. Var nyfiken och dela med dig och du lever längre – eller i alla fall roligare. Det är vad jag försöker leva efter – så några bakutsparkar till lär det nog bli.

Have you tried a BBQ board? Or a travel spike? Or a homework burnup chart? How about Limiting WIP in the kitchen, or the closet? How about agile party planning? There are plenty of ways that Agile and Lean practices and ideas can be used to make life at home more simple, pleasant, and fun!

There are two recordings of the talk: here and here. The talk is in Swedish though, and the sound quality is pretty bad. And the tempo is very high – it’s a 10 minute lightning talk after all )

In the slides I’ve added english subtitles (well, speach bubbles actually). Wanted to try that instead of writing an article, what do you think?

Enjoy! And please share your own tips and tricks!

• It’s serious play, these games shape the outcome of of real products for companies like Cisco today
• I was a bit skeptical about trying them online, but I find they can provide alternatives to retrospectives for distributed teams.
• It is as much about the reasons we reveal for our choices, as the games itself.
• I find the games can help developers (and product owners) learn about the (unspoken)  needs of market segments and user groups. Understanding the rationale of their choices is key to designing a good solution.
• If I was a sales person, I’d jump on them right away. Way more fun than death by power point.

Here’s me asking some questions to Luke.

The audience was great! Thanks everybody! I certainly didn’t know everything there’s to know about the subject, and that resulted in an interactive session where people from the audience would share their experience and answer some questions. That was so cool

Anyway, the point I wanted to make was this: when you google for Selenium/WebDriver and Ajax, you still find plenty of examples where the naïve approach, sleeping (as in Thread.sleep() and similar constructs) is used. My main message was – don’t ever do that! Use a proper WebDriver wait, since it handles the sleeping correctly and plays well with ElementNotFoundExceptions.

I also mentioned implicit waits as something that can be used if you don’t have too many Ajax calls and want to hide that complexity behind a global timeout.

My second point was that there is a category of Ajax calls that have no side effects on the DOM, i.e. when the call completes, nothing happens in the DOM. The example was validation by third party libraries. If you control the code, you can always make it affect the DOM somehow, but not if a third-party library handles the call. In such cases you can intercept the Ajax sending function and the callback using Javascript. In the sending function, a counter can be incremented, and it can be decremented in the callback. This is a canonical way of counting the number of ongoing Ajax calls, and variations of this technique should work with every Javascript library out there with some tweaking. This might not be a silver bullet, but it has worked well enough in our tests.

I actually never got the question why I ran all my code samples as unit tests. None of them actually verified anything; all they did was to print things to stderr. Apparently the reason wasn’t interesting enough, but if it made someone wonder: It was because I wanted my samples to be easy to turn into tests if necessary.

By the way… I totally forgot to mention the AjaxElementLocator* classes.

Some comments and suggestions from the audience:

• Implicit waits don’t help when waiting for elements that are not there
• You can check for non-presence of elements by waiting for the element to be present for 0 seconds and accepting the exception.
• If you need to, and can, add Ajax call counting in the code of the page, not by injecting the variable through Javascript. (The latter assumes that you don’t have control over the tested page.)
• Don’t rely on jQuery’s active variable to check for ongoing Ajax calls. It may indicate other activity as well. (True, but you would probably want to wait for that too in your test, so it may not be that big a problem.)
• There is a class called org.openqa.selenium.support.ui.ExpectedConditions (in Java) that has a lot of static methods that can be used as predicates for WebDriverWait. That way, you don’t have to implement them from scratch. (I simply didn’t know that.)

All in all, I think we had a productive session, in which we unfortunately didn’t find a sliver bullet for the asynchronicity challenges, but we managed to exchange a lot of knowledge and got a common view of where the API is, and what techniques we can use.

The slides are here, and I plan to post the code samples on Github soon. Stay tuned.

Anyway, here are the slides

Paul Graham describes two different schedules, the manager and the makers schedule, where the former is run by managers working through the day participating in a lot of different meetings, and the latter is run by the workers, the developers and project participants, working through the day developing new versions of the product they are accountable for producing. These two schedules have their place in an organization, but we may get in trouble when the two schedules meet each other, which they do now and then during a normal working day.

Meetings cost quite a lot, and it is often not obvious for the managers working under the manager schedule how big that cost really is. I believe we need some kind of structure, an agreement between the meeting participants and the organizer of what they need to prepare and do before the meeting, in order to guarantee that it will be as efficient as possible. This to ensure that the organization get some kind of ROI from having the meeting.

Structure of an effective meeting

In general I run my meetings in the similar way as most agile chops organize their retrospectives, where you should have a similar structure as the following five points:

• have a dedicated facilitator that help the group build on each others ideas
• visualize the agenda which describes the different steps the group will go through during the meeting
• express a clear goal with the meeting; what should the group have achieved when the meeting is over?
• provide a description of how the group should work during the meeting, how the group will be organized in order to work towards the goals
• and finally, end the meeting with a short recap of what have been achieved and all action items are restated so that everybody agrees on them

Using this structure the group organize itself better and is more focused on achieving the purpose of the meeting. Meetings without this structure have easily just turned into a discussion without reaching any decision point. These meetings have in many cases just ended with a decision to schedule another meeting to continue with the discussion. Since most organizations are really busy, this should of coarse be avoided by all means.

READY/DONE criteria

Looking at the meetings from a different angle, I believe that we should organize the meetings as timeboxes, where each one has a fixed length and and a agreed on scope, focus for the meeting, and end with a delivered goal at the end. One way of improving the efficiency of the timebox is to use the concept of READY and DONE criteria described by Jeff Sutherland, where the READY criteria describes the detail level of the requirements for them to be accepted into the sprint. The DONE criteria then describes what should have be done in order to say that the requirement has been delivered as requested, The two criteria are used to make the expectations on groups up and down streams from the team, explicit to everybody. They may also act as a baselines for further improvements regarding the collaboration between different groups.

You could use the READY and DONE criteria when organizing the meetings as well. The READY criteria describes what the meeting organizer should have prepared and have done before the meeting is started, and the DONE criteria describes what the group should strive for and have achieved at the end of the meeting. The meeting organizer is accountable for reaching READY, and if the participants don’t feel that the criteria is met, they may cancel the meeting and ask the organizer to prepare the meeting better. If the READY criteria is met, the group is accountable for reaching DONE, working according to the structure described in the agenda.

An organization should always strive for improving itself, and you can use the READY criteria as a tool helping you creating an efficient structure for your meetings. Let the different groups having short retrospectives around the meeting structures where they improve how they are organized, and capture that structure in the READY and DONE criteria.

Value driven meetings

Thinking further around the READY and DONE criteria and how they are used in Scrum, and the possible use of them during meetings as well, got me thinking about the purpose of having meetings at the first place. I believe we have a tendency having to many meetings, where many of them are run without any clear link to how it will bring the organization or project closer to its goals.

In Scrum, the READY criteria describes how much details and information you should provide to the Scrum team regarding a user story for them to accept it into the sprint backlog. And, the story describes some kind of functionality that should be developed to achieve a value; both user value and organizational value. The team shouldn’t develop stories that have unclear value since without the value you do not have any business case for developing the story. Working further down this thread, the value of a user story should be linked to what you are trying to achieve with the product as a whole; you should have integrity regarding the purpose and value of the product and the aggregated values of all its different parts and functionality.

You should think in the same way regarding you meetings. Before deciding on setting up a new meeting, you should be able to answer the following question (in either the organizational or the project context):

• In what way are we, by running this meeting, bringing our organization/project closer to our goals?

If you cannot answer this question and therefore not able to describe how the goal of the meeting is bringing value to the organization or project, you should have another thought about what you are trying to achieve and why you would like to spend your colleagues precious time on the meeting. It should be clear at the beginning of the meeting in how the group is bringing value to the organization by having the meeting, and in what way the desired result will bring the organization closer to its goals. All activities should be linked to the organizations goals liked this, but especially meetings since they, by the very fact that we are gathering a lot of people at the same time, is very expensive. You need meetings, but make sure that you only have meetings that are bringing value and a high ROI back to you.

There is an easy way of getting both: change your statement into a question. This will trigger an intellectual challenge and proof that people have a viable idea. In short: It enables more options.

Turn:
“It can’t be done” – into – “why is that hard”?

The solution we have are only limited by the questions we are asking.