Asier's thoughts

Blogging about software development

Leave a comment

Judge the code, not the developer

I’ve been paying attention recently to conversations we have at work. I can hear people complaining about the code, how bad it is, not readable, difficult to make changes.. They will refer to the people who wrote it. And I do it too! Even if we don’t know who wrote it. It doesn’t matter, is ‘us’ and ‘then’.

  • They wrote this crazy stuff.. why??”
  • somebody had this idea of creating this hierarchy of classes. Look now, how can we extended this class without affecting this other??”
  • “look, a developer added an extra call to the service here. This is making our application not to perform well.”

We are judging the people, instead of the code. This just creates tension between co-workers. It creates a difference between the person who wrote the ugly code and us. We are kind of saying they don’t know how to write code, do they job properly.. ultimately we are just saying they are inferior and that we are better than them. We judge them.

We can just change our aptitude if we detach the code from the people.

  • “this crazy stuff.. why??”
  • “this hierarchy of classes. Look now, how can we extended this class without affecting this other??”
  • “look, there is an extra call to the service here. This is making our application not to perform well.”

We would still be stating the same thing: the code is bad, not readable, difficult to make changes.. BUT we won’t be judging people, our co-workers, our team mates. We will be all in the same boat seeing the same problems and ultimately fixing them together.



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:


    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:

Leave a comment

Lasagne Pattern

If you have a mess in your code where methods are being called from one place to another in such a way where is really difficult to follow the flow of the program execution this is known as Spaghetti code. Following with the Italian cuisine allegory, if you have too many layers of abstractions this is known as the Lasgane Pattern.lasagne-alla-bolognese-HEM1

I am just surprised how many times I have seen this anti-pattern in place! It’s typical in client server applications where programmers have learnt about the importance of a N-layer architecture and with a bit of cargo cult programming they end up overusing it.

In software, a n-layer architecture it’s a way of separating the code of an application in different components or modules. The code will be separated around different concerns. The typical separation of components is presentation, data access and business logic. If we are talking about a server-client application another component will be added to deal with the communication between both. If you draw an image with all the components like layers one above the other with the database at the bottom and the UI on top, it looks like a n layered or multi tier architecture. We can draw arrows from the presentation layer to the database to see the flow of the actions.


This is a good pattern and basically almost everybody follows it. The problem is when developers start adding layers just for the sake of adding layers! One layer more for the cache, another one for the application etc. Then you end up with loads of layers and many of them doing nothing, just delegating calls to the underlying layer.. To make it even worse different type of objects will be used between layers (Entities, DTOs, ViewModels, Ducks, Chickens..) with the extra work of having to map from one to another. If you add to this the need to unit test every single layer you will end up with a lot of work to do just to get a single record from the database!!

If you are not careful a misused n-layered architecture can bring a lot of unnecessary complexity. My advise is to use the least amount of layers possible (And store procedures are considered a layer). Don’t put layers just in case, software is cheap to change later on. Yes.. I know, architecture is not that easy too change, but still it can be done, try to deffer that decision as much as possible (maybe you can do some prototyping?) and be wary about layers.

Reference: I don’t know who came with the name, but I heard about this anti pattern first time in coding horror. Though there is called Baklava Code.