A tale of two browsers.

Allow me to share with you a tale of self deception, indirection and eventual discovery.

“Users are having trouble when using firefox on a mac”.

“What?” I said. Wondering how that could possibly be. “There is no way the code could be causing that. I reckon it’s a setting on the users computer”

“A setting? Ok you’re the expert. I will ask the user to check their settings”

Well, I thought “problem solved” and back to the business of coding. Plus I run everything through firefox on my windows machine and it works just fine.

A few days later our customer service manager reached out again.

“We are still getting complaints that the site isn’t working on firefox on macs. People can’t click the buy now button”

“Really?” I replied. Thinking again what it could be. There’s no way it could be my code. “I wonder if they have a firewall that is blocking the payment API”

“Will ask them and let you know”

“Ok, thanks” Damn firewalls, always messing with our applications. Great, now where the heck was I in the stack trace…Oh damn the API timed out.

The application was still in beta testing mode. Only to a handful of select users. No one uses firefox anymore, and anyway we suggest using chrome.

Everything was looking good. Getting closer to rolling the application out globally. Hadn’t heard back from our customer service manager. Must have been the firewall, great. Lets go live…

“But people aren’t able to purchase the product when using firefox on a mac.”

“Who uses firefox anyway?” I replied. Still convinced the code would support all browsers and operating systems.

“Customers! We have to fix this. We will lose business and reputation”

Can’t be my code. “What version are they using”

“57.0, the latest”

Mmm, I thought. There must be something weird going on at the OS level, or maybe a bug in firefox. “Ok, let me look into it”

So I found a mac with that version of firefox. Mmm, doesn’t seem to be working. Wonder what console is logging. Must be something really messed up.

Nothing, no errors. Nothing. I had no idea how to fix it. There was no point debugging my code. There was no way it could be causing this problem. I knew it back to front, it passed all the unit, integration and user acceptance testing and I never made mistakes like this. I had no idea how to solve this problem.

Could I have made an error?

Turns out, yes. Really simple error too.

You see, the document.activeElement property works differently on iOS.

“For iOS, elements that are not <input type=”text” />, will not get focus assigned to them. The property will then return BODY or null.” 1

So this is the technical explanation of why it wasn’t working on iOS. Simple to find where the code was breaking and fix it. But why did it take so long? Why wasn’t this found sooner. Why didn’t first I simply admit to myself it could have been my code, looked into it and dealt with it.


My own ego.

The common definition being:

  1. a person’s sense of self-esteem or self-importance.

Yes, you see a senior developer like me could not have possibly made that error.

But how to address this, learn from it and prevent it from happening again?

A beginners mindset? Humility? A rule of thumb?

Yup, all of these should do it. Acknowledging and trying to understand our own psychology is worth exploring. Stepping back and finding some objectivity. Noticing the signs. Being self aware. Meta cognition.

Accepting our shortcomings is difficult. Accepting we could have made a mistake is the first step to being able to correct it. Owning our mistakes and learning from them is where growth really happens.



  1. https://www.w3schools.com/jsref/prop_document_activeelement.asp

Test Driven Development is Hard

Really hard.

Sure, writing a contrived test for a simple function is pretty straight forward. There are many frameworks that developers use, and some will even form the test stubs for you. Having the discipline to always write tests is a challenge. Writing test first for weakly defined requirements is difficult. Retrofitting large and complex legacy code bases get hard – and costly.

Test first promotes modularity, clear requirements and acceptance criteria. It encourages thoughtful domain modelling and ensures code works as intended. But what if you don’t have clear requirements, if you inherit a mud ball of legacy code, the language is new and the budget tight, where do you start. How do you decide where to focus your efforts, what parts of the code to test and what to refactor?

The first thing is to commit to writing unit tests. You then need buy in from stakeholders – users, analysts, managers and fellow developers. This is an important and valuable exercise. The stakeholders need to know what’s in it for them. This can help get a team focused and all pulling in the same direction. So, what are the advantages of test driven development for project stakeholders.

Users: Test Driven Development encourages users to think about their business requirement in clear terms. This results in quality applications that satisfy user requirements with less errors.

Analysts: Encourages requirement gathering that is clear, organised, atomic and written with well defined acceptance criteria.

Managers: Higher quality applications with less errors. Lower lifetime cost of software by lower cost maintenance.

Developers: Can rest easy knowing their code works as intended. That requirements are clear and changes are nothing to fear.

Once the testing framework has been established, in the case of legacy code you might find that that much of the applications features cannot be tested. The logic is split between layers and classes, there are branches that cross multiple classes and layers. It is then time to refactor the code base. Check out Martin Fowlers book Refactoring.

New features should have tests written first. This should be manageable as the user requirements are now well defined and thought out with clear acceptance criteria. Happy managers that see the value in unit tests and developers who can make changes to the code with confidence. Developing software is a team effort, and test driven development can help focus a team. The best time to start test driven development is your next line of code.