Image for post
Image for post
The women’s eight representing GB at the 2017 World Rowing Championships © Naomi Baker

Today we live in a time where building and delivering high quality software, fast and frequent is a necessity. Having assembled teams who have done this relatively well and having worked with teams who have not managed to do this so well, I have come to appreciate certain qualities of teams that I thought I should pen down. So here we go.

They self-organise

The team can plan and get something meaningful done without needing a manager to guide them or define things for them. They understand the big picture and collaborate within the team to figure out the what and the how with productive discussion around the why. Leaders emerge out of self-organising teams who become drivers of initiatives and those leaders motivate the team to see the importance and value of those initiatives. …

TL;DR they don’t.

Image for post
Image for post

It’s been quite a while since I adopted RxJS and fell in love with the idea of Reactive Programming. It takes time and quite a bit of practice to really get to know reactive programming and learn to appreciate it. When you start playing with RxJS one of the first things you would notice is the similarities of an Observable to a Promise. The next thing you would do is google “promise vs observable” and the internet will explain to you what the differences are quite well.

I’m baffled by the number of people I come across who think observables are a replacement for promises. I guess we have Angular to partly blame for that. Despite Angular playing an important role in the fame and adoption of RxJS, it did play a part in this misconception with its use of Observables for use-cases where Promises are more applicable. …

When you travel out of your resident country there are things that you miss quite often. One of those things that most people end up missing is the caller-id when you receive calls from your resident country. This happens mostly because people tend to save phone numbers without the country code for local numbers. This bites you back big-time when you are traveling. I recently moved to Singapore from Sri Lanka and it has been a blast, except when I get calls or WhatsApp messages.

So I wanted to convert all my Sri Lankan contact numbers that did not have a country code to have one. Usually I would use Automator on my mac to get this sort of little tasks done. But this time it was too much of a stretch for Automator to include all my nitty-gritty requirements to get the job done. Enter JXA (JavaScript for Automation), something that Apple included in Yosemite as an alternate to AppleScript. …

Picking the right software architecture/design is just like picking the right tool for a job. You use the wrong tool and then everything may seem a little bit more difficult or little bit more messier. When it comes to software architecture/design though, there is no such thing as the “correct” tool for the job. Most solutions would work and the difference would be relative. It really boils down to how optimal a solution is, for the problem(s) at hand.

When we started rebuilding Creately from scratch, we revised a lot of our design and architectural decisions. One of them was to use Event Sourcing as one of the key patterns in the overall solution. …

RxJS is something I have come to appreciate quite a bit in the recent past, in it’s ability to manage asynchronous operations. It really is a shift in the programing paradigm of how you look at asynchronous code. If it is adopted consistently well across your app, you can see a significant improvement in how you manage asynchronous code. In this post I want to talk about a particular principle of Observables. This post wouldn’t make a lot of sense if you have not had exposure to RxJS.

Unsubscribing or Cancelling.

One of the key features of Observables is its ability to cancel the underlying operation of the source. In fact the ReactiveX documentation explains the primary purpose of the Subscription as this. …

In the second part of this series I talked about how we actually deliver our products every single day - the process and the tooling. In this final post I want to discuss why some of these practices are important to achieving the level of efficiency you need to deliver quality product, fast.

When we start a new project, there are a bunch of things that we setup to ensure the smoothest and fastest operation of that project and the best quality outcome of that project. …

Anyone who is an experienced application developer understands that if your application is not the typical todo app, you have at least a few states that are application wide (they conceptually exist regardless of how they are implemented/handled). There are lots of powerful ways to maintain states well (like routes, singletons, storage and so on). But it all boils down to how you define them and use them.

Why disaster?

Centralized states can be a disaster for the very reason why global variables can be the same. When there is a central/global state, it can affect different parts of the application and at the same time it can be modified by different parts of the application. Trying to understand how a specific part of the application works, will depend on any global states that are affected by it or modified by it. This also means one specific part of the application will be bound to another part of the application by these states. As the application grows it becomes harder and even impossible to understand how different parts of the application are affected. …

In the first part of this series I spoke about what this whole thing means for us. In summary the three key focuses are: World-class product quality, fast delivery of smaller things and automating everything. In this post I will be going through how it is done.

How we work is what enables us deliver product everyday.


Each of our projects are on their own git repo. Each project is bootstrapped with package management, linting, code styling, unit test coverage reporting and a full-on build process. Every repo has

  • a dev branch which aligns with staging environment.
  • a master branch which aligns with production environment. …

F**k that.

I fully appreciate the notion of not taking failure as a negative emotion and I have practiced that many a times. Failure happens and there is so much that you learn from it and almost every failure is a gain, not a loss. So telling yourself “it’s ok to fail” when you fail, is one thing.

What bothers me is whenever I see a Startup or even any sort of initiative that is driven with the safety net of “it’s ok to fail”. This I feel sets you in the wrong direction all-together. If you are being scientific about how you think (not emotional) you can 100% of the time plan meticulously to achieve the set goals. Yes, it is true that no one plans exclusively to fail. …

In today’s age and time, if your product team is focusing on anything other than building great product experiences, your competitors won’t have much trouble gobbling down your slice of the market. There are many things that can eat up the time of your product team. One of them is delivery.

Continuous Delivery is no magic. You will find many ways to learn and make CD work for you. I’m not gonna talk about that. This series is going to talk about how we adopted a scalable way of working for Delivering Product Daily.

Delivering product fast is no brainer if you are a small team of coders. You may be able to even push code instantly to production depending on the competency of your team. As your team grows and splits into multiple smaller teams composing of different skillsets and skill levels, you need to start thinking about maintaining the quality of your pushes and overall product. So here are your key concerns. …


Hiraash Thawfeek

Coder, Creator of things, Entrepreneur

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store