What I learned from building a large-scale application for overseas clients
The I.T. industry in China is a rapidly growing market. Over the last 1 year in Hong Kong, I’ve been lucky enough to work on an exciting project. I’ve also had the chance to learn something that’s never encountered before, making a major milestone for a career.
Like many other projects, it is better to have every team member in the same place. I worked with the remote colleagues in different time zones, including Pacific Standard Time, some with UTC-06:00, and others with UTC+10:00... but it’s not ideal in terms of productivity.
The other challenge is you need to speak the customer’s language. For those of you who speak Chinese but can’t type fast, I would recommend learning pinyin input method in order to catch up with the fast conversations in QQ chat.
To foreigner’s surprise, China has censorship of Github, so you can’t simply use npm install && bower install within the firewall. Hosting on AWS and some analytics tools are also blocked, so you have to find alternatives. Besides, your colleague developers may have a different work style instead of adapting scrum methodology or use JIRA board for visibility.
Our public beta test of the Ember application, however, has a performance issue. The initial load and rendering are pretty slow, even though Ember has nice development tools. To make things worse, at least 20% of customers have low-end specification computer with an old browser. I was stunned to witness Windows XP turns to the blue screen of death by simply loading font awesome icons. Eventually, we solve this biggest problem by refactoring with vanilla js. Although the speed is awesome, the amount of code written is doubled with a triple amount of states and bugs to handle, which is not ideal either.
We’ve learned one important thing the hard way. In retrospect, you need to have full control of the delivery pipeline, otherwise, you’ll never release. It’s an art to ship early and often. We spent months working on 3 re-designs, unfortunately, it’s still not able to launch regardless of all the positive feedback we received. It’s too risky for big cooperate to change, and it’s too hard to overcome the big cooperate’s culture with fear of change.
With this project experience, we have learnt a lot in both the tech side and project management side. Shipping early and often is the best practice, and I hope to apply some of these techniques to other projects in the future.