The 2015 BAQ Conference and Career Paths for QA Engineers

This September Lviv hosted the BAQ Conference (Business Analytics and Quality Assurance) bringing together quality assurance engineers and project managers. It was a new and unique conference for the Western region of Ukraine, gathering business analysts and professionals in software testing.

The conference was intended for experienced specialists wishing to present and discuss new ideas and trends in these sectors. I was attracted by the likelihood that a wide variety of people from different cities were expected to attend and I believed I could learn something interesting.

The conference was organized in the hall of a hotel in the Western Ukrainian city of Lviv, full of stunning architecture and good-natured people. Its quaint narrow streets seem made to inspire new ideas or to reflect on current practices.



There were two parallel sessions for QAs and PMs. I chose the QA session, consisting of 8 presentations varying in content and in exposition: from technical aspects of testing to working with Agile projects to psychological techniques for working in a team and building relationships with new employees.

Most of the presentations were well put together. In this post, I’d like to highlight the topics I felt might most help a QA engineer in how she/he wished to develop career-wise. Given the avenues of project management (PM) or automation QA, how to decide what is best and most suitable for you? This was best addressed by two speakers: Tetiana Golubieva (who works as a PM) and Andrii Lazarev (working in automation QA).

Project Management

Taking Tetiana’s angle first, what we should expect on the path to becoming a PM?

Consider what a manager is: a person whose role within an organization is to oversee the achievement of project and business goals. This is bound to entail a learning curve for anyone accustomed to manual QA work. QAs work according to well-defined plans: receiving a build, testing it, filling out test documents, writing a status report, and repeating the process, on time according to a well-defined schedule. Many aspects of managers’ work are quite different to this. It is less routine and more improvisational, and requires balancing business goals with client and staff needs. It seems to me that a PM should be able to anticipate events, or at least be able to react quite quickly to the unexpected, as well as find a language common to a wide variety of people.

While knowledge of the process being managed is essential, a mentor would be very nice to have so as not to have to learn everything through trial and error. Besides a mentor, what else might help the novice manager? Reading books, attending conferences, and, of course, the ability to both think and feel his or her way through problems. And a new manager should be responsible. Ultimately it’s the PM who bears greatest responsibility for deviation from the objectives of a project.

Automation QA

Turning to Andrii, what about becoming an Automation QA engineer? Andrii’s material was most memorable to me, being comprised of many things I am faced with daily. And his presentation was the more understandable for me: everything was clear and interesting. So what’s challenging about the transition to automation QA? Technical knowledge. Some basic tools you need to understand for automatization include Selenium WebDriver, BDD framework, at least a basic understanding of HTML, working with CSS / XPath / jQuery as well as browser debugging tools such as Chrome Dev Tools or Firebug, maybe a programming language or two. This is a lot for a beginner!

My choice is JS given that 90% of Web applications are written in JavaScript. Two books that have really helped me are: JavaScript: The Definitive Guide, 6th Edition and Head First HTML with CSS & XHTML. If you don’t have the technical background but are driven, you’ll be working overtime, each time asking yourself “How do I do this?”. If you have senior who can serve as a mentor, listen to him and try to build a chain of his reasoning in your head. The development of technical capability requires quite a strict mentor in my opinion, but also someone who can explain things in plain language, as clearly and succinctly as possible. A good mentor is half the battle! Andrii insisted that moving to automation QA is much easier than it sounds. I’m not sure I completely agree, but I do know that if you set and keep to a goal, eventually you’ll succeed.

One of the most important qualities for an automation QA engineer is discipline: test refactoring is best carried out at least once a month, and learning Continuous Integration tools is a huge plus. But the main thing is to not compromise quality!

So whichever way a QA chooses to grow, whether towards a PM role or towards test automation, will not be easy. Deep study, hard work, overtime and some amount of trial and error are inevitable. But after a time, if Tetiana and Andrii are to be believed, you will see significant results. That is surely worth it!



Quality Booster: Continuous Integration and Continuous Delivery

Let’s start with an assertion that needs no proof: everybody likes to see progress in what they are doing.

After a hard day on a construction site a carpenter can see results of his work, an artist can see her sculpture taking shape through her efforts, a teacher can sense his students making progress. Any of these can present the results of their work at any moment in time and their employers, customers or clients can see the difference in the work from where it was previously.  

So, repeating myself: observing and showing real progress from an effort gives satisfaction and confidence and bolsters one’s will to persevere.

Now imagine yourself making an enormous efforts or paying significant sums of money each day and seeing absolutely NO real change in the project you are working on for… a month… two.. half a year… How would you feel about this and what thought would come to mind?

sisyphus bildreihe

The fact is the above situation is real world scenario if we’re talking about software development. A typical software release schedule ranges from one to six months. In the interim, a project is treated as “unstable” and can’t be presented until all features planned for the new release are implemented, tested, and stabilized. Project stakeholders have little to do except eagerly wait for the new release. Yes, they can watch how tasks are moving from a project’s backlog into a sprint and then into the “done” column – this might brighten the waiting and show that a project is moving in the right direction. But this is hardly a substitute for the ability to see actual product progress and to try a new feature as soon as it’s implemented and tested.

Wouldn’t it be nice to have a client see her product evolving in real time? Wouldn’t it be nice if a client could check out every new feature while the task ticket is still warm?

I’m talking about Continuous Integration (CI) and Continuous Delivery (CD). Let’s look at how these can be achieved, with an emphasis on the latter, and what mandatory prerequisites are needed to set up Continuous Delivery.

First let’s clarify the difference our terms.

Continuous Integration is a software development practice that requires developers to integrate code into a shared repository several times a day.

Obviously we are not going to present our code repository as evidence of “progress” to a client.

Continuous Delivery is a software development practice in which teams producing software via a feature-based approach ensure that their software can be reliably released at any time.

ANY TIME! That’s what we need!


Seriously, back to CD prerequisites, the dependency chain looks like this:

CD > CI > Automated Testing > Unit tests > Loosely-coupled System Design where each system component can be tested separately by injecting all its dependencies.

Continuous Delivery is the summit of your system, the uber-aerobatic hat trick of software development if you will – it requires all aspects of your system to be done right.

If developers were sloppy in controlling dependencies, if the automated testing strategy was not thoroughly thought through from the very beginning, if unit tests’ code coverage is low and not maintained on daily basis – this means CD is a non-starter because you can’t control the quality of the project automatically (and your vehicle is not ready for aerobatics).

Implementing CD means thoroughly testing each system change. The quicker you can find out if a change breaks something the better. In the ideal case it is very easy to find the root cause of an issue since we already know what change is causing problems and the developer can be notified immediately (and automatically). This takes product quality to a whole new level. And it’s the reason “fail fast” is a key principle of CD.

Graphically, the CD process can be described like this:

CD process

In addition to client satisfaction CD brings additional benefits such as

  • building the right product – client can test features early and change the project backlog if needed.
  • predictable and reliable release schedule – we are always ready for a release. Yes, the set of features implemented for any given release will vary but a stable application can be released any moment.
  • high product quality – since the majority of defects are captured in the early stages of development it is easy to identify and fix them.

As for the tools that make CD possible, several years ago there were no options other than custom scripting that would glue together code repository, unit tests, deployment and automation testing. Nowadays we have Jenkins, Hudson, GoCD and similar solutions which can help loads with CD. Just make sure the tool you are going to use has release management capabilities and get clear about how you are going to manage releases since there are going to be a lot of them. You should be able to easily track what features are included in any given release.

This means your CD process must be integrated with your task tracking system: it can be quite tricky, but for most larger project definitely worth the effort! How large? CD is definitely not for small (two or three month) fixed-bid projects. But I would say that having code architected for testing and unit testing from the beginning is good practice for any project. Then, if the MVP debuts successfully in the market and the client decides to continue development – this is the time to invest in CD. 

Summing up I want to encourage you – demand continuous delivery from your development team!


Rush Hour in Vietnam: Teaching Us About Business


First time visitors to Vietnam universally take notice of the heavy rush hour traffic in Ho Chi Minh City and other big cities across the country. The mass of cars, taxis and scooters looks like a crazy mess, especially for those of us accustomed to driving in western countries. Lane markers are suggestions only. Traditional right of way rules for vehicles entering traffic circles are definitely not followed in Vietnam. Traffic circles are not the only issue – for pedestrians, just crossing a street can be quite an experience. Cars merge from side streets or from a parked position without waiting for an opening. I’ve witnessed a taxi make a complete U-turn on a very busy street with tens of scooters and other larger vehicles approaching from each direction. Behavior like this would might get you arrested in a place like Palo Alto.  Fortunately, the only conventional rule followed is stopping properly and in time for a red light. At first glance, traffic flow in Vietnam appears to be the victim of poor planning and lack of manners. However, after watching traffic over many days of cab rides from my District 1 based hotel to our office on To Hien Thanh street, I began to see the Ho Chi Minh traffic from a much more positive perspective. 

I’ve begun to substitute my original anxiety and fear with the recognition that this system actually works. I now see traffic flow in HCMC as a harmonious orchestration of millions of people getting about the city. There is a smooth elegance to a large mass of movement. It reminds me somewhat of of watching a school of fish in an aquarium window. I don’t see any road rage. People honk horns, sometimes often, but taxi drivers and others are notifying a scooter to the side or ahead to be careful, “I don’t want to run you over”. Drivers don’t really go fast, usually because they can’t go fast, but when the road opens up a bit, it’s uncommon to see drivers accelerate to fill the space. Predictability and flexibility are key. There are lessons learned from how people negotiate traffic that can be applied to building software.

Self Organization

The most important analogy seen by watching rush hour traffic to a software development project is self organization. In Vietnam, traffic is much more self organized than in Western countries. The Agile Manifesto states that “The best architectures, requirements, and designs emerge from self-organizing teams”. Traffic in Vietnam works well, given the enormous number of people out on the roads, due to this self organization. Getting from A to B in HCMC can take some time, but you will get there, predictably and not in a frustrating amount of time – it will never take hours. It is hard to imagine that on US or German roads that one could arrive in a comfortable time frame with as much traffic. With LA or Bay Area traffic, everyone would just grind to a standstill if we applied our Western traffic systems to Vietnamese traffic volume. It would be a huge disaster. The ability to self organize and problem solve together allows this system to work, even with the huge volume of drivers served.


Secondly, the importance of the collaboration is highlighted by the Vietnamese traffic. Groups of scooter drivers stick together to get around larger vehicles or form lines or pods that benefit the group of riders. The Forbes article “The 12 Habits Of Highly Collaborative Organizations” points out the natural befits of collaboration in a business organization, including learning to get out of the way and integrating into the work flow as two of the articles main principles. When you ride a scooter, you are unwittingly participating in a team of other scooters around you and applying many of the principles of collaboration to make it work.

Not Taking it Personally

Lastly, drivers in Vietnam just don’t seem to take anything personally. There is no point to prove to someone else, no one that you have to put in their place. This allows small violations of one’s personal space to just roll off easily – you move, adjust and work together.  The point is to get where you want to go safely, relatively quickly and reliably every day. 

Creating Value

Until they were acquired by Facebook last year, I was a big fan of the Canadian digital agency Teehan-Lax. Of course their design work drew me, as did their famous (and famously free) iOS and Android PSD files, but what really kept me coming back to their site was how Jon Lax, one of Teehan-Lax’s founders, wrote about their business

One of the most memorable bits of Jon’s writings, which I’ve assembled from screenshots and pasted below, was a list called “Ten Things We’ve Learned”. As I recall this list was composed after Teehan-Lax had been in business for a decade or so. Having been in consulting and services businesses for most of my career, I see a lot of hard-won wisdom here.

10 Things-sq-red

And I’m happy to say that on a recent visit to our Kharkiv development center I witnessed something which reminded me of one of my favorite items: #6: Create more value than you capture.

I had arrived in Kharkiv on a Saturday night, and the next day I headed into the office to get a jump on the week’s work, expecting to find it more or less empty. And it was, except for a gathering taking place in one of the rooms.


There, on a sunny Sunday afternoon, were six women, each working at a computer as she listened to a seventh giving a talk, occasionally standing up to write some notes on a whiteboard. The woman talking was Alena Bachurina, one of Waverley’s Lead iOS engineers. I asked for permission to join them, and during a break it was explained to me that they were gathered there that day the way they were most Sundays, to learn about object-oriented programming techniques and iOS development.


Alena, who has a well-earned reputation within Waverley for being an exacting software architect and highly effective iOS engineer, had decided some months earlier to offer these lessons, free-of-charge, to any woman who might be interested. Her Sunday class had come to be known informally as “iOS for Girls”.

Although the stuff on the board looked fairly hard core, not all of Alena’s “students” were techies. Our office manager was among them, as was one of our PMs. I was especially surprised when I learned one of the women taking part was employed at one of our competitors. I stuck around for half an hour or so, shooting a few pictures, not able to follow the Russian but basking in the group’s camaraderie and shared purpose. In a male-dominated field, here was a top female engineer sharing her considerable skills with a circle of “sisters”. 

And here was Waverley, offering its office space and one of its shining talents to help improve the skills of, among others, a competing firm’s employee. I thought of Jon’s Ten Things and felt the satisfaction of recognition. Teehan+Lax was a great agency, and I was sorry to see them go. But here was a little bit of what they stood for, showing up in another business, another language, another culture. 

Alena earned further esteem from me that day. It seems fitting that, courtesy of Waverley, she’ll be amongst 5000 people in attendance at WWDC 2015 in San Francisco.

HTML5 for Mobile – Will One WebView Ever Rule Them All?

HTML5 is no longer a new technology. But despite having been around a few years, its potential has never been fully realized, especially on mobile platforms. Since its introduction something has always been missing, preventing HTML5 from ever being fully embraced as a serious platform for mobile app development.  


First it was the lack of implemented standards – I remember checking with each new browser version release, eagerly hoping for a score above 300. Then came the era of “performance nits”: developers wrestled long lists to get a smooth scroll and did backflips to get transitions that felt “native”. Fast-forward to today (mid-2015): performance is less of an issue but still requires very close attention – one sloppy CSS rule or DOM modification and the veil is lifted.

And JavaScript memory management has always been a sand trap. You might think JavaScript will handle things smoothly with dynamic memory implementation and garbage collection. Not on mobile devices. If you’re developing for devices where resources are limited, the JS GarbageCollector becomes your enemy, sucking performance from your app any time it pleases and leaving you with no control over when it springs to life and blights your seamless animation. And although you can say “it’s not me – it’s GarbageCollector”, no one will listen: you’ve just gotta learn to deal with it. Here are a few tricks JS developers can perform to mitigate this issue:

All in all a bit long and unless you’re a JS developer you may not want to sit through it. Let me just cite the narrator’s definition of JS GarbageCollector: “waste monster which keeps your applications from going too fast … a blind beast filled with hate and rage.” I can only grin and applaud that characterization. So if you are a JS developer watch this video carefully. It contains the best description of JS’s GarbageCollector algorithm I’ve ever come across together with an effective approach for taking control of this “beast”.

Imagine trying to keep memory under control with a few junior JS developers on your team: throw in a few folks with HTML-level coding skills and no clue about memory heaps, stacks and other low level stuff and the beast roars bigger than ever.

And returning for a moment to the era of “performance nits”, speaking from experience I can confidently say that the only way to get 60fps from an HTML5 mobile app is to avoid HTML and CSS entirely, relying instead on a single hardware-accelerated canvas which runs WebGL underneath. Yes, you’ll have to implement the UI yourself but resulting app will be fast. And there are several good libraries which can help.

But this post is not about WebGL libraries since the state of the art puts “performance nits” in the rearview mirror. Instead there’s a new threat building around mobile HTML5 – WebView fragmentation.

WebView for HTML5 is a Common Language Runtime – that means it’s supposed to be “common” on different platforms while allowing us to run Javascript HTML and CSS. That’s the theory. Practice is another matter. Taking a closer look at what’s out there now:

Android 2.2  to Android 2.3.7 – WebKit version 533.1

Android 3.2.1 – WebKit version 534.13

Android 4.0.1 to Android 4.3 – WebKit version 534.30

Android 4.4.x – WebKit version 537.36

Android 5.0.x – WebKit version 537.36, upgradable separately from Android version!

Today, developers can expect Android 5 devices that, despite their common base OS, all run different WebView versions. Compounding the problem is the fact that some Android device vendors are “tweaking” default WebView, leaving developers to sort out “device specific issues”. And unfortunately there are many of these.

Now let’s look at the Android versions market shares:

Screen Shot 2015-05-11 at 8.47.12 PM

Data taken from here

As for Apple – with iOS 8 they introduced fast WKWebView instead of regular UIWebView but, as of this writing, about 17% of Apple mobile devices were still running iOS 7.

iOS fragmentation

And that’s just looking at Android and Apple. Matters get even more complicated once you consider platforms like Tizen, Blackberry, Amazon Kindle, and Windows Mobile, which has its very own WebView implementation.

With so many WebViews in the field the reality is that each has specific defects that developers need to be aware of to then apply corresponding workarounds. And as noted here, nobody’s going to fix previous versions of WebView even when bugs are really severe. And if big bugs get glossed over you can imagine how much attention minor malfunctions get…

More than ever before, HTML5 developers have to deal with a bewildering array of issues: Webkit version specific, OS/Platform specific, device specific and in addition to all this – wired memory management. As a lead engineer who’s been working on a big HTML5-based project for about three years I can confidently say that navigating this labyrinth and while building automated test systems to maintain control on product quality absorbs significant time and resources. Time and resources that are comparable to those required to create two native applications…    

So welcome to the era of WebView fragmentation. With each new WebView version in the field, added to manufacturer-specific “tweaks”, HTML5 supporters are losing their last and best argument in favor of “hybrid HTML5” vs. native. “Build once run everywhere” is becoming a form of wishful thinking. 

Business Continuity Planning: Turning Crisis into Opportunity

For the past three years, we’ve been operating our premier development center in Kharkiv, Ukraine. With world class universities and abundant talent, Kharkiv has a vibrant technical community of young coders, developers and system architects, talent that attracted us to Ukraine in the first place. Over the past year however, Ukraine has unfortunately experienced war and substantial loss of life in the central and southeastern parts of the country, about 200 km (125 miles) from our office in Kharkiv, but thankfully with few disturbances in Kharkiv itself.


We made the choice to operate in East Ukraine, and we have to be accountable to our clients and our employees for that decision. As the conflict in the Donbas began, we realized a business continuity plan was warranted. In March 2014, we began to test our plan and had some interesting experiences as a result. We’re continuing to watch the situation and plan accordingly. Obviously, responding to a crisis is not an experience we would have chosen, but it’s nonetheless made us a better organization and left us much more flexible and prepared for the future.

To design our continuity plan, we looked carefully at how our organization can move staff or transfer mission-critical business responsibilities to different physical locations. We observed that moving a development project staffed entirely in a single location to a new location is very hard to do. Team members are also people with family ties and relationships and while a move to a distant location may be appealing for some, it’s rarely the case for every member of a team. Additionally, Waverley and client investments in the team’s skills and project-specific knowledge as well as “tribal knowledge” gained from a team’s long-term engagement are critical to the success of the deliverable.

One just can’t wind down a team in one location and restart it in another with all new people. However we can and have taken steps that benefit everyone: our clients, our developers and their families.

The process of learning how to make this transition started by chance at the conclusion of 2013, before initial unrest in southeastern Ukraine developed. At that time, a group of my top developers came to me with a request to work a few months in Montenegro to find relief from the cold Kharkiv winter. It was an opportunity to reward our team with working in a remote location that happened to be near the Mediterranean.


The developers knew that they would have to work successfully in a distributed environment, so the motivation to think and plan for a great outcome came from the bottom up rather than the top down. It all worked fantastically well. We measured no loss of productivity. In fact, the Montenegro-located teams showed a marginal increase in productivity.

People working from Montenegro and their counterparts in Kharkiv built the ability to work in a distributed environment. They learned how to communicate, plan and count on one another. So when tensions in Ukraine started to become apparent, Waverley already had this successful experiment in its back pocket, and we knew we could grow a new location quickly and with confidence in our ability to perform. Without the prior experience in Montenegro, temporarily relocating a significant number of people on short notice would have been near impossible. Our staff was very grateful to have the option to spend part of the 2013/14 winter in a warm place. With this one experiment, we were able to demonstrate concern for their well being and at least one means to respond in case the Donbas crisis spread.

As a separate effort, we accelerated our plans to grow build a development center in a second Ukrainian city. In mid 2014, we opened an small office in Lviv, a vibrant city in West Ukraine, far from the Russian border and pro-Russian southeastern provinces. We have developers who have relocated to Lviv from Kharkiv and we are actively recruiting new positions in Lviv. Staffing a new office with existing people presents major advantages over a new office with all-new staff: existing staff bring with them the culture and internal know-how that allows Waverley to perform so well.

We’ve taken our plans even further by actively working on multi-country teams between Ukraine and our Vietnam location. Integrating both locations into one Waverley been important to growth and opportunities for both Waverley and our clients. Our teams in Ukraine interview staff for positions in Vietnam, and wherever possible, they work together on client projects. This experience enhances our ability to move responsibility for deliverables as needed and provides an important “shadow” capability on a global scale.

During the last year, we’ve come to realize that the opportunity to plan and execute continuity plans has many benefits. The ability to accept a difficult situation and look for opportunities for improvement is core to our culture. We know we can never plan for all eventualities, but adaptability, flexibility, and performance, in our code and in our operations, directly influence how we go about the day-to-day business of building great software for our customers. We will continue to respond to events and work hard to continue to be a dependable partner who can be trusted to deliver.

Motivation, Performance and Career Growth in Scrum/Agile

Teams using Scrum on regular basis can get bored. This is especially true of higher-performing teams. The smoother the process, the easier it is for team members to start feeling they’re working in a factory: demos and retros become mechanical, all failures are in the rear-view mirror, all disputes are resolved, top-management is happy and the team is held up as a model for less mature teams. You’d imagine such a team would live happily ever after but…

Experience has shown that a team that has attained such a high-performing state requires extra attention from its project manager. Yes, let’s assume this team has a manager looking after each member’s career path and keeping them motivated to do a great job. And at some point this manager starts to notice signs of boredom: the discussion of the project lacks enthusiasm, creativity is thin on the ground, and challenges are met with a shrug. This is the right time to do something differently.

Certain professions observe the tradition of hanging diplomas and certificates on an office wall for clients and patients to see. These symbols, some might call them trophies, indicate competence, success in one’s training or work, excellence, professionalism.



Consider a similar approach to designate that someone did great during a Sprint. This can be a “star badge” (for example) given to an engineer during the Sprint’s retrospective meeting by the rest of the team. It can be for anything the team wants to appreciate about that person. 

Scrum talks about team commitment, team performance and team responsibility on deliverables. And this is all good when things are going fine and no problems occur. On the other hand when a team fails a Sprint, it’s often hard to pinpoint a weak link. Team members will tell the project manager that all of them are “good guys” working hard against incomplete requirements, unexpected difficulties in deployment etc., and if possible they will blame anyone outside of the team for the failure: managers, the product owner (especially if the product owner is customer-side). It’s a pretty rare case that a team will admit failing a Sprint delivery due to their own overestimation of their competence, wasted time during the Sprint, lack of discipline, miscommunication and/or not escalating issues early enough to other team members or the Scrum Master.  

And here starts the person-by-person performance analysis, work review etc in order to try to separating well-performing team members from, em, ballast. A little humor goes a long way towards lightening the mood here. During sprint retrospective meetings the Team can decide which members (if any) deserve a “Zombie” badge for their meh performance, lack of feedback, blocking work of other team members, etc. 


Here’s another reason this personalized, trophy-based approach is useful. Teams often consist of developers of unequal experience and seniority and line managers need to do performance reviews for each engineer as a member of one or more Scrum teams. While these reviews constitute  important feedback in each engineer’s career plan you’ll be hard-pressed, as a line manager, to get negative feedback from the other members of that engineer’s Scrum team. Handed out at regular intervals, the trophies are fun but also serious: something simple and agile allowing the tracking of each team member’s successes and failures without taking lots of time from PMs, Scrum Masters (or whomever is doing this job in your company).

Here is the simplest evaluation system: have a table that’s shared with all the team members, then assign an excellence mark in front of each team member name using the following rules:

  • Assign 3 if the team member performed extra work or took something to a higher level on-time and with good quality.
  • Assign 2 if the team member did good work and accomplished all the tasks assigned in time and with good quality
  • Assign 1 if the quality was not so great, leaving some bugs for future Sprints.
  • Assign 0 if tasks were left incomplete without a valid reason.

Then, in a brief discussion with Team Members grant the Stars and Zombie Badges if any are deserved =)

The idea is to use a developer’s total score to rank his/her performance over an extended period of time. Calculations are simple: people with top scores and more Star badges are the first to get salary raises, bonuses, days off, go to a conference at company cost… anything you use in your company as positive motivation. On the other hand if for some reason your project budget gets cut you know which of the current team members you can release without remorse. And your choice will be supported by these simple metrics.

Finally, I have already described the importance of having FUN while working. Add some gamification to your Retrospective meetings and I promise you wouldn’t get bored during Planning nor during the Sprints =)


C-THRU: Transparency and Simultaneity in App UI Design

A recent app UI design effort had us face what has become a familiar problem: optimizing the use of screen real estate on mobile devices. Given the limited screen size typical of most mobile devices, here’s the dilemma:

1) increasing app sophistication often leads designers to want to display more UI elements

2) any elements displayed must be sized to allow easy operation with one’s fingers

Compounding this problem is the drive of most designers to “simplify”, a bias towards minimalism artfully represented in Apple’s “a thousand no’s for every yes.” 


In this particular case we were designing a consumer-facing native iPad app called Kinoke. Part social network, part private journal, part photo/video album, Kinoke’s proposition is to get users to reflect on, comment, and share personal letters, photos and videos in a totally private, non-commercial way (invitation only, no ads, no collecting and re-selling user data). Given that the demographic includes older users, the UI had an even greater need to be simple and uncluttered. 

The heart of the app is where users comment on a particular item, say an old family photo. We call this the Comments screen. We were designing this screen at the pixel level, and we hit this impasse to do with balancing simplicity, complexity, and accessibility.

The Comments screen needed to be simple so users would not give up trying to use it the first time they tried, and so that they would return to it often and with pleasure. It was also going to represent something complex, a display in which the old photo and related comments could coexist without one compromising the other. And users had to be able to quickly shift their focus from the old photo to the  comments and back again … both had to be instantly accessible.

We considered devoting about half the screen to the old photo, placing user comments adjacent. But this forced both the photo and the comments to be smaller than we wanted. We considered flipping or panning the view to alternate between comments and photo. But this was going to put a lot of distracting movement on top of what we knew would be a moment of concentrated contemplation. Having elements fly in and out of view is great sometimes, but maybe not when you’re trying to put words to a memory or feeling, especially if you’re 70.

We knew we had to get the Comments screen right, because that’s where the users create value in the app. We wanted no movement, we wanted the photo and the comments to each be as large as possible, we wanted near-simultaneity. All that led us to a control that would let users modulate a two-tiered space using transparency. We call it C-THRU.  

thumbnailHere’s how it works. User comments, whether typed, audio or video, are displayed on a dark background through which a full-screen version of the item being commented is just visible: in the background but very faint. Near the left edge of the screen sits a circular button labeled C-THRU, and this button does exactly that. When touched and held, C-THRU rapidly cranks the transparency of the dark comment layer up to about 90%. The underlying item becomes clearly visible, but this effect lasts only as long as the C-THRU button is pressed. As soon as C-THRU is released, the dark layer returns, the item fades back behind it, and we’re back to typing or speaking or videoing our comment as before.

One user described C-THRU as “putting on x-ray glasses.” We feel it lets users remain fully immersed in a task while giving them the chance to observe two things seamlessly. 

And C-THRU really paid dividends when we took on the task of porting the Kinoke iPad app to iPhone a few weeks ago. With even less screen real estate on tap, the C-THRU button’s effect of quietly transitioning between the two tiers of Kinoke’s Comments screen seems indispensable.

My First Trip to Vietnam

Amongst Waverley’s multiple development centers, the largest are in Kharkiv, Ukraine and Ho Chi Minh City, Vietnam. Engineers at both offices work on similar projects (at times they collaborate on the same projects) and have been getting positive feedback from our clients. As the lead QA Engineer in our Kharkiv location I’ve developed a good working relationship with our QA team in Vietnam but didn’t know any of them personally. On top of that I didn’t have any first-hand experience of Asia. I discussed this with two of our executives: Matt Brown (CEO) and Patti Gosselin (COO). Soon after that meeting I ordered tickets to Ho Chi Minh City and started planning my trip. 

I landed in Ho Chi Minh City at midday. A project manager from our Vietnam office met me at the airport. He was so friendly and happy to see me that I decided to visit Waverley office first and check in to my hotel later in the day. 

It was mid-September so while still warm in Ukraine it’s nothing like the 77-86F I was met with in Ho Chi Minh City. But I’d checked the weather and I expected it to be hot. What I didn’t expect was a perfect taxi service. I’ve never encountered better taxis than in Vietnam. The drivers are instantly recognizable in their green uniforms and just need to hear the address or see a business card. As in Kharkiv most people in Ho Chi Minh don’t speak English but those “guys in green” do. If you don’t see one nearby you just call a taxi service (Vinasun is the best one) and ask for a car.

VN triptychThe heat out on the streets contrasted nicely with the temperature inside the office. Good air-conditioning was common in Ho Chi Minh – seems like air conditioners are everywhere. In fact, regarding work places, work stations, equipment in the office – everything felt similar to offices in Europe and the US. I’m not sure whether this applies to all offices in Vietnam or only the Waverley office but staff report to work at 8-9 AM and go home around 5-6 PM (in Kharkiv most of our staff arrive and leave two to three hours later, to synch with clients in the US). During the working day the folks in our Ho Chi Minh office have coffee breaks and a one-hour lunch. What I appreciated in their working process: synchronization. At any time you can find a technical specialist in the office; no need to call or chat via Skype to ask a question. Also people in the office prefer to have a lunch all together: it’s like small team-building exercise every day. And what was unusual for me: people sleep in the office if they don’t want to go for lunch or finish lunch early. So during the lunch break it’s possible to have a meal and sleep a bit to refresh brain and body.

During my visit I asked to have a one-on-one meeting with each QA team member to get a sense of strong and weak areas of their knowledge. After completing all meetings I concluded that the team is very motivated to work in IT and have good educations, almost everyone has a technical background, they understand the testing process and generate proper reports, and all are willing to learn more and grow like into true technical specialists. I did at times have difficulties understanding their English pronunciation. Often Vietnamese omit final consonants and medial sounds, confuse sounds etc but I think it’s just a question of time and practice on both sides. The more one communicates with people from Asia the better understanding of their English one has. And any problems are really limited to pronunciation. No problem with their writing and they also understood my spoken English well. 

For me in my first visit, Vietnam felt like an unusual country. Food is different, a lot of scooters and motorbikes and innumerable very small shops – not like in Europe or the US where we can buy everything we need in a supermarket. People are very polite, friendly and ready to help at any moment. What I really appreciated and what stayed with me was the sense that anything a Vietnamese person does, he or she does out of consideration for the welfare of the family, rather than for themselves alone. 

I am definitely interested in visiting Vietnam one more time to shake hands with the people I met, to meet new people and get a feel for Vietnamese culture one more time. And I hope to do it soon!  

Future of JS – As Discussed in Barcelona

This past May the JavaScript community gathered at the FutureJS conference ( in Barcelona, Spain. After a few years of semi-stagnation JavaScript has been seeing renewed interest amongst developers. With browsers approaching the status of operating systems for the Web, JS as the principal browser language is getting a lot more attention. 

FutureJS addressed contemporary issues of JS development. Speakers included Jeremy Ashkenas – creator of CoffeeScript language, Reginald Braithwaite – author of the book JavaScript Allongé, Patrick Dubroy – Google Chrome engineer, guys from Facebook and others.

I was keen to get a “vision of JS’s future” directly from the people who call the shots. And it’s always helpful to step away from  everyday work and broaden one’s understanding the current state of JS and Web technologies.

The event was well-executed with balanced time for talks and coffee breaks. Evening meetups in hip bars and, during the day, long lunches (yes, it’s Spain and they take their siestas seriously) provided ample opportunities for informal communication amongst participants, organizers and speakers, including a great wrap-up party in one of the best night clubs in Barcelona (Razzmatazz).

Overall there were fifteen talks over two conference days (video archive is here). Some were dedicated to the JavaScript language itself: its history and possible future evolution, including the newest features of the just-emerging ES6 standard. Summing up the highlights for me: 

Reginald Braithwaite on Functional Programming and OOP

Reginald’s talk emphasized JS’s inherent minimalism. The language doesn’t contain ready functional constructs or concepts and doesn’t force us to use a functional approach, but has enough tools for developers to code in a functional style if they prefer (functions as first-class entities). The same with OOP – JS doesn’t support all the concepts of classical OOP, but Reginald showed how we can emulate them using objects and prototypal inheritance.

Reginald also explained the idea of creating modular programs based on functions, thereby making code more reliable and reusable. According to this approach a program consists of two groups of functions: ones that implement business logic, main building blocks of an application; and service functions (composers, transformers) – general-purpose routines applied to the business logic blocks or to another service functions (they are going to be the same for different applications). For this approach to be successfully implemented the business logic functions have to be properly isolated and encapsulated.

Jeremy Ashkenas on Using JS in Commercial Projects

Jeremy, author of the CoffeeScript language, the Backbone.js JavaScript framework, and the Underscore.js JavaScript library described lessons learned using JavaScript in big commercial projects. He listed the main evils of JS: incorrect polyfill implementations, prototypes hell, different types of functions, scoping of var and others. Also Jeremy explained how CoffeeScript allows developers to avoid all those issues. And CoffeeScript being very similar to JS (in syntax and main concepts) makes it a relatively easy step towards more reliable, intuitive and comfortable programming (the caveat being the additional step of compilation).

Patrick Dubroy on ES6

Patrick toured us through its new features (specs can be found here) with an emphasis on how to use all these goodies just now when most browsers don’t fully support them. While such features as new methods of API can be easily polyfilled, the new language syntax and constructions require more cunning approaches. Enter the compiler Traceur. It takes code containing new ES6 features and transforms it to ES5 (or even ES3) compatible code. Patrick also demonstrated, through examples, exactly how transformations from ES6 to ES5 are done, from  elementary ones like the => (lambda) operator to more complex stuff like generators.

Jaume Sanchez on the new Web Audio API 

Jaume explained its main idea and constituent concepts. Web Audio ( enables the mixing, processing, and filtering tasks that are found in modern desktop audio production applications. The model of Audio Nodes – audio processing nodes connected into the processing net (or graph) – is the key concept of the Web Audio API.

Martin Naumann on Web Components 

Martin described the use of Web components ( to build modular Web applications. The coolest thing about Web components is that developers no longer need specialized frameworks and tools (like angular directives) or components built with other languages and technologies (for instance, Java applets) to create reusable, well-isolated, reliable widgets for Web applications. Standardized technologies like Shadow DOM and custom HTML elements can be used instead.

Pete Hunt on the Virtual DOM 

Peter presented the virtual DOM as an alternative approach of organizing data binding in situations where current approaches were not ideal from a performance perspective. The classical implementation of data binding is based on the key/value collections observation (Ember, Knockout). The main competitor of this approach is dirty checking (Angular). The virtual DOM bumps performance while working effectively with the data binding update history: the current state of bound UI elements is determined as a collection of changesets applied to their initial state.

Matthew Podwysocki on Event-based Programming

In Matthew’s memorable talk on reactive JavaScript programming he explained the idea of streaming and event-based programming using FRP (Functional reactive programming) and RXJS. He described the main principles of reactive programming: observable and observers, query operations and schedulers. Through vivid examples Matthew demonstrated how RX (reactive extensions) works in practice. The API for reactive programming in JavaScript is offered in the RXJS library. The idea of reactive programming is not new (I first came across it two years ago when I worked with MS .NET technologies), but there are interesting trends in its development, like using it in conjunction with JS generators (ES6).

All in all, attending the FutureJS conference gave me a clearer understanding of which aspects of JS and Web programming I should learn in depth and start using in real life. High on my list is functional programming implemented in languages other than JavaScript – Haskell, Scala, Closure.

I came away feeling that the future of JS is filled with promise, excited to get back to work!