arrow-flex-shortarrow-flexarrow arrowsbinocularschartcogsflex-icongeargithubglobelightnings linkedinlock plantscalestarget triangle-icon twitter

Play More to Work Better

Dziamid
April 23, 2019

Education starts in the playground. Good education starts in a well-established playground. At DVELP we believe in the importance of play in the everyday life of a developer. We encourage developers to play early and play often. There are two major reasons behind this.

First, playgrounds allow you to stress test your ideas before they reach the primary codebase. Should you realise that your masterpiece is not optimal, you can throw it away with a calm heart and nobody will see, unless you wanted to.

Secondly, playing is a huge stress-relief factor and a driver for innovations. Get inspired by the story of two brothers from Bagdad who, out of joy, invented the first programmable device - a giant music box. When I put my brain in a sandboxed environment and let go for some time, I often find myself experimenting and broadening my understanding of the technology I play with. I find it much more effective than going through the docs for the tenth time.

Let me give you an example of a playground I’ve been using extensively for a recent IVR project. At DVELP we have very well established approach to building reactive systems (such as an IVR). Central to the approach is the notion of the FSM (finite state machine). I find Sketch Systems to be an immense help in prototyping state machines as well as a lovely interactive environment to play with.

At a very high level: the IVR system accepts the call, helps the user to make a booking, waits for the call to finish, does some wrap up activities and hangs up.

IVR Diagram

The good thing about Sketch Systems playground is that it allows you to start prototyping at whatever level of abstraction you are currently most comfortable with. You can zoom in (refine) to add details or zoom out to add more context.

Let’s refine the ongoing call step

IVR Diagram 2

I encourage you to follow the links below the images and enjoy the interactivity by clicking on the action links (e.g. “incoming call”) and see how the state transitions.

Now, the implementation detail of the IVR is out the scope for this article. What’s important is that once I’ve spent some time playing with my sketches I found a slew of insights for the overall architecture. Namely: how to name actions and states in a consistent manner, the relationships between the states. Overall, the time I spent playing with the diagram was compensated by a shorter implementation time and most likely saved us from a few potential consistency refactorings and bug fixes.

Next time you feel like trying something new, reach out for playgrounds and remember Michael Jordan's advice for success: "Just play. Have fun. Enjoy the game."

Articles

By using this website you agree to our cookie policy
x