Asier's thoughts

Blogging about software development


Leave a comment

Standardisation kills innovation

I’ve recently re-watched the video from Spotify about their culture at work. It’s a really cool video, if you haven’t watched it yet you should. I’ll wait.

Part 1

And part 2

It’s been a year since I first watched it. I understand now much better many of the things they talked about. I guess because these are things I have experienced through the last year.

One of the things that stuck in my head is that autonomy is more important than standardisation.

In Spotify teams are quite autonomous. They make their decisions based in their own rules instead of following some general company rules. Rules are not good when you want innovation. Standardisation kills innovation. How can you try new things if each time you want you have to change some rule in the company? How can you learn? How  you grow? Isn’t it better to keep this rules down just to the team? You will just have to convince your team instead of the whole company!

I’ve seen a pattern coming into place in software companies who are changing from product to project teams, they are adopting standards! In these companies teams instead of working in a specific product in a company work in different products all the time. Each product will be changed by more than one team through its lifetime. In order to make everybody’s life easier everybody will have to be on the same page. Therefore the need to standardise everything: which tools to use, frameworks, naming conventions, coding standards, methodologies, ways of testing, branching, deployments, code reviews, how to write a commit message.. You need to have the same rules for every team so changing from one product to another it’s not a pain in the ass..

Now, let’s say you or your team doesn’t like one of these “rules” or just thinks it could be improved. Good luck if you want to change any of that easily.
Standards make change hard, they give no much autonomy to teams and makes continuous improvement difficult. And autonomy it’s important not just for innovation, also for job satisfaction as mentioned in Drive: The surprising truth about what motivates us.

Advertisements


2 Comments

Implicit vs Explicit Waits in selenium

The last few days at work we have been fixing some intermittently failing tests in selenium. In the process I came to learn the difference between implicit and explicit waits.

The needs of waits.
When running a test against an application UI sometimes you need to wait for an element to be present. This could be due to the whole interface taking time to fully load or just a small part of it.

When we jumped to fix these tests we saw that they were doing what they mean-to and that the application was really doing what the tests said, but the problem was down to page or elements or the page loading slower that expected. Waits would be our allies in our battle.

Two types of waits
There are two type of waits you can use in Selenium: implicit and explicit waits.

  • Implicit waits are defined for the whole test suite.
    Every time the selenium driver tries to find an element on a page it will wait a certain amount of time before throwing an element not found error.
    By default the implicit wait is 0, this means the driver won’t wait at all.
    This is how you define the implicit wait of 3 seconds:

    Driver.Manage().Timeouts()
    .ImplicitlyWait(TimeSpan.FromSeconds(3));

    Each time the driver looks for an element (i.e using Driver.FindElement(..)) it will wait 3 seconds before failing. If it finds it before it will continue with the test run.

  • Explicit waits are defined just for a single purpose.
    For example we could wait for a progress bar to finish, a pop up to hide or an element to render.
    This is how you define an explicit wait for the body element of 5 seconds:

    var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(5));
    wait.Until(d => d.FindElement(By.TagName("body")));

    If the driver doesn’t find the html “body” element in the page within 5 seconds it will throw an exception. If it finds it before it will continue with the test run.

For both cases the driver will constantly check for UI changes. If the the element is present before the time it will continue, it won’t keep waiting.

Favour explicit over implicit waits
By rule of thumbs you should favour explicit waits over implicit. If your tests is failing because certain element takes time to load add a explicit wait for that element. You could also fix the problem adding an implicit wait, but that would affect the whole test suite and make tests slower and you wouldn’t be addressing the underlying problem.
In the other hand, sometimes the whole website could be slow and pages would always take a few seconds to load. In those cases it’s ok to add implicit waits, but I wouldn’t recommend any more than 2-3 seconds.

[+] info: