The Challenge:
Your team is excited about the potential benefits of WebAssembly. Your team wants to try it in their application. How, as a team member, do you approach this?
Suggested Answer:
Prioritized Goal:
We need to identify where we should improve rather than doing a random walk. Hence as a team, we start our journey of identifying the wildly important Goal from a list of Goals. A SMART Goal with a tricky “m”.
We work towards collecting doable Usecases, by creating a relative score matrix with the following tentative vectors:
a) customer delight thanks to quicker response – Positive
b) reduced load to servers – Positive
c) reduced defects due to improved testability – Positive
d) complexity in modernizing within a reasonable time period – Negative
This should help us to reason and prioritize the Usecase that has the potential to offer us the right benefit within a time. Of course, We baseline the “value of the current situation” for future comparison which is use-case specific.
Leverage every idea:
On a number of occasions, we need to apply more than one strategy to reach our Goal.
If I were driving the developer of selected use-case, then
- I will not hesitate to assess if my design is right. Design and algorithm make the cornerstones of an elegant and efficient solution. If I have the right design and algorithm in place, it is adequate for me to squeeze the best possible performance.
- If the problem is with DOM Manipulation and re-painting the canvas, there are lesser chances for WebAssembly to help me here.
- I will look for areas that involve heavy I/O operations. I will check if I can decouple that aspect to a combination of WebWorkers and WebAssembly. This may make the main thread available to converse with the User which may improve the customer delight eventually.
- I will apply all the possible ideas like JavaScript, WebWorker, and WebAssembly judiciously to improve the situation.
- I will listen to my team for out-of-the-box ideas and steal them shamelessly.
- I will look if the bottleneck is shifted to a different place because of the small improvements, to avoid solving a problem that no longer exists (“phantom problem”)
