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.

Ego.

My own ego.

The common definition being:

noun
  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.

 

References:

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

Digital Products and Marketing

There are compelling reasons to sell digital products online. The cost of distribution is low and the marginal cost per unit is virtually zero. Once the product is created, and a market found, digital products can be downloaded by consumers effectively an infinite number of times. Payment gateways are numerous and the costs are a small fraction (1-4%) of the purchase price.

For New Zealand domiciled entities, GST (Good and Service Tax – 15%) is not collectable on digital products that are downloaded offshore, however GST may be claimed on expenses incurred in New Zealand. This deliberate government policy is to encourage zero weight tech exports from New Zealand, earning the country valuable foreign exchange.

Over the past few years, I have sold several digital products online. This category included several e-books and some software. I used ClickBank as the payment gateway. This was easy to use and the fees reasonable, however there is a lot of junk on there. The e-books covered topics such as how to quit smoking “The Quit Smoking Book” and how to trade CFD’s and Forex. These sold for around $29.95. Over about two years I sold about 4-5 copies.

The software was a tool for SQL server admins and developers called the “DDL Extractor”. Basically it did as the title said, it extracted the database’s data definition language (DDL) to text files that could be searched, archived and added to source control. The first version had simple command line interface. I updated it to have a basic windows form GUI. It sold for between $19.95 and $49.95. Again I sold about 4-5 copies over two years.

All the products had their own domain and website. The pages had relevant content and sales copy. I created all the pages from scratch and hosted on GoDaddy. Marketing was mostly done through Google Adwords, Facebook ads, writing posts on Ezine and mentioning my products on forums such as stack overflow . All with links back to the relevant product sales page. The least effective and most expensive was Adwords. My account eventually got suspended for reasons more cryptic than a wet crossword puzzle. After weeks of trying figure out why, it turns out that at the time Adwords didn’t like pages that directly linked to a payment gateway. Nuts to that.

So, after all that I made around $300 of sales, and that’s before domain registration, hosting and the countless hours spent in the evenings writing coding and marketing. After all expenses including depreciation I accumulated about $5000 in losses. Epic Fail.

After a hiatus of about two years, I still like the idea of having a suite of digital products for sale. Having people find, pay and download a product you created – to solve a real problem – is a great feeling. Having payments rolling in while you are sleeping is also a great buzz. However, it must be profitable and the market must be large enough to sustain a business. How to achieve this has as yet, escaped me.

A few years ago Amy Hoy of Unicorn Free and 30×500 fame did a talk at a conference I attended, WDCNZ. I found the talk interesting and decided to follow her on Twitter. After reading many of her blog posts I entered my email address and began reading these posts. I’ve really enjoyed reading them. The basic premise is that you figure out your market before creating a product. It also explains just how to do this. One of the posts was the inspiration for me to start blogging again.

Now, to find that Market Product fit.

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.