Return to site

Tech talk: Engineering at KAWO

by Alex Duncan

written by Ricky Ng-Adam in collaboration with Gregory Orton and Frédéric Bazin

As part of our weekly Tech talk, Alex Duncan join our Coderbunker community on a Saturday at lunch time to talk about engineering at his startup, KAWO.

Alex Duncan is the product lead at KAWO, a SaaS (Software-as-a-Service) publishing platform for managing your social media presence in China. It’s pitched primarily at brand managers, agencies, and teams who must communicate and organize their publishing schedules and strategies. Customers of note include 92 wrestlers of the WWE (World Wrestling Entertainment), Manchester United, UFC and NYC. KAWO is a productivity tool that saves time for brands and agencies.

Alex studied zoology at University. He was lucky to have an Apple Mac at home as a child which gave him a very early start in design and some basic scripting. While at university he funded his studies by founding and running his own design agency and honed his web development skills. He has no formal training in design, programming or UX, but he can claim practical skills and boast hands-on experience across many years and many projects. He was forced to work hard to improve theoretical gaps in his knowledge.

Alex gave a quick overview of how KAWO provides history, control and traceability to the agencies and reliable posting to the social networks.

Three years ago, the first version of KAWO was primarily built by only two people: Brian van Damme (the current CTO) and Alex Duncan. Alex was in charge of writing the frontend for the first couple of years and they have since grown to a team of 9 engineers. Growing beyond a two person teams turns into a very different dynamic. They need to think more long term, invest in efficient development and maintainability. Since they are responsible for fixing bugs in the future they have a real vested interest in quality and save time.

A key to saving time is to focus on automating deployment. From staging to production, KAWO depends on Gulp "the streaming build system" for deployment. Because their deployment is automated, they can deploy up to several times a day. Minifying CSS, resizing images, moving images files, substituting identifiers specific to each environment is complex and would be 2 to 3 hours of manual work that is replaced by a 20 seconds build and deploy.

Since their humble beginnings to a major player on the market, they've made what is in hindsights a lot of good decisions and some bad decisions in engineering. Alex underlined how important it is to be careful about the decisions you do early in a project as the product turns rapidly into legacy code with thousands of lines which can't be easily changed to update to the latest and greatest.

Their engineering team heavily track analytics, using both Google Analytics and Mixpanel (Mobile Analytics), generating 2-3 megabytes a day of data. At KAWO, everybody needs to understand analytics; from the frontend developer knowing where to put the analytics snippets in the HTML code to marketing using analytics to figure out if marketing campaigns have been effective. They also use analytics heavily in user review sessions where they decide to fix bugs and improve or trash features based on actual usage.

They've made a major push recently towards testing. They use Casper to automate a test suite that is more focused on functional testing instead of unit testing. Their interactive script test 10 to 50 different things and acts as a smoke test to make sure nothing is broken, either as account administrator and end user. Testing is key to prevent repeated hotfixes into production.

When they were starting, Alex was heavily influenced by an article Mailchimp.com wrote about their pattern library (http://ux.mailchimp.com/patterns/about). Early on, Alex moved the company to a visual component system based heavily on CSS, enabling non-frontend developers to implement a hand drawn sketch design directly into a feature for production without any designer support because a common visual language is established early on. Their documentation are HTML files with a simple Javascript snippets to extract and display code snippets directly from that HTML.

This fitted well with Alex philosophical approach to not use opinionated frameworks (such as Angular), favoring targeting libraries-like dependencies such as Backbones and Virtual DOM (a core technology behind React that abstract and manage deltas to the DOM optimally). They prefer building their own libraries, own micro-features or micro-components rather than pulling a lot of unnecessary cruft that behaves in multitude of ways. An example is Moment.JS: why pull in complicated calculations and variety of display formats when everything is built for China time? So they did exactly that; standardizing on one presentation format for dates and reducing significantly the size of their dependencies.

KAWO Components have the unique particularity to be in pure CSS; no fonts, no images, no SVG. This enables the developer to include widgets without having to worry about including external assets. It also gives the interface a unique flexibility that recalls the great pixel arts or ascii arts of early computing. To use the latest and greatest features, they've made the conscious decision to only support the latest browsers (Chrome, Firefox and IE11).

Alex, show me your source code !

Why not use Bootstrap as the framework for their frontend? 3 years ago, Bootstrap was still a bit immature and difficult to customize. It also pulled in and created a lot of dead, unused code. Customizing, although possible, was painful. Having their own visual components enabled them to move quicker and more simply while establishing their own signature visual presentation. While you should avoid deliberately wasting time or overcomplicating things it is also important to allow members of your team to focus on areas they find interesting. A frontend developer with a passion for CSS is unlikely to get as much satisfaction out of building a frontend in bootstrap and the end result will likely be better if you allow them to exercise their passion for clean CSS.

Features are generally per release cycle but some major redevelopment can last months and are subjects to extensive discussions in Github Issues discussions spawning from where the data should be transformed for the presentation layers (in the frontend or backend?) to usefulness of features. They aggressively get rid of features that are not used.

They've also carefully integrated data mining into their engineering. As much as possible, they try to turn data insights into actionable information for the users in the frontend. This can be from K-means clustering of posts to making recommendations as to when posts are most engaging during Chinese new years.

A day in engineering at KAWO starts with a 10min huddle. Training new developers is a big investment at KAWO; they spend 30 minutes to 1 hour daily with new developers for months at a time. There's no documented checklist to onboard a developer; it's all interpersonal human contact to not only transmit culture but humanize the onboarding process. They hire for overlapping skills; specialized engineers but with an understanding of how all the parts work from frontend to database. Their hiring focuses on personality traits, such as attention to details.

Finally, for tech startups Alex recommends patience. Built it for yourself first (KAWO’s first customer was also their initial investor) and focus on being great at that one thing.

Join the next talk ?

Speakers can apply at talks@coderbunker.com

Join our community on http://www.meetup.com/Coderbunker/

or just follow us on wechat.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly