Forem: Anton Vasin

No Code tools are either hype or niche — you should opt for niche

Anton Vasin — Thu, 16 Sep 2021 10:35:18 +0000

No-code is a broad term. It describes a vast set of products that help end-users assemble web pages and applications without hiring developers.

In recent years, it has also become an ideology of sorts (praised, for example, in this Forbes column): a promise to get rid of all complications that are intertwined with IT development — its proverbial high costs, unpredictability, and difficulty to scale the teams fast enough.

However, I’d argue the promise is often exaggerated, as the proposed approaches are oversold and/or not particularly new. Still, niche solutions from the no-code toolbox might get your tasks in certain pipeline parts done surprisingly well.

So let’s pick apart the ideology and get into what startups and businesses should consider when thinking about no-code solutions.

No-code is not particularly new

Speaking of no-code, we usually think of it as a recent development, a step made in the late 2010s to emancipate the world from expensive engineers. Be it Notion, Mailchimp, Voiceflow, or Bubble, companies associated with no-code approaches are usually recently found startups. But is the approach actually that recent?

In fact, no-code-like tools were there from the very beginning of the computer era. Take Microsoft Excel: it’s basically a way to embark on visual point-and-click methods to create a simple database instead of using SQL. Or any graphical operating system like Windows, Mac OS, or Ubuntu: they give users a command line functionality combined with visual means, without the need to learn code-like commands.

This point also perfectly illustrates the limitations of no-code. It is no coincidence that most operating systems still have a command line-based core and give their power users access to it: some things are just intrinsically difficult to visualize.

Yes, a lot of people don’t touch the Mac OS X Terminal and never will, but in most cases, somebody terminal-savvy needs to be around to perform any actions above a certain level of complexity.

No-code limits patterns of thought

The visualization and simplification, these pillars of no-code, come at a price: no-code tools usually nudge a client to a limited number of patterns — in fact, that’s exactly what allows them to get rid of the code.

Say, only a certain number of product management techniques go hand in hand with no-code task management tools such as, say, Trello. As a result, the idea itself might become stale.

The problem with patterns is that they deny you the possibility of learning. A salesperson can’t become an expert in business only by using landing page presets. The code usually gives you almost infinite possibilities of configuring the system (open-source culture and the competition of approaches, programming languages and libraries usually guarantee it in any given field).

It might not be that important for the first project, but crucial for the growth and future of any professional. There are some domains such as computations or high-load systems performance where you can not simply ‘no-code’ your way out of complexity.

That’s why I and my team at Readymag, a browser-based design tool that helps create websites, portfolios and all kinds of online publications without coding try to avoid staleness at all costs in our solutions, never limiting our users to presets, always giving them access to a clean canvas. We also give our users tools for coding.

Good tools have precise scope

However, I firmly believe that no-code approaches are great when it comes to a narrow-scope task. Take Zapier, a tool for API integration, that we actually use in Readymag; or Airtable, a tool to automate the creation of CMS.

The idea here is not to waste your time on something that can be easily automated and configured, still use the power of engineering for the necessary parts.

Another example is specialized e-commerce tools such as Stripe or Ecwid. Instead of creating our own e-commerce sub-tool, we at Readymag have integrated them. We try to leave each part of the pipeline to the specialized tool, be it code or no-code.

And we think of Readymag as another such tool — a web editor, great for interactive graphics and interactive UX, but possibly powered up with additional APIs or custom code for larger and more complex projects. A full-fledged no-code approach is limiting, but a specific no-code tool might significantly increase your development process.

Summing it up — never buy into no-code as a mantra, but always keep an eye out for its niche practical uses.

What makes Feature Flags a path to faster and safer development

Anton Vasin — Fri, 20 Aug 2021 12:07:22 +0000

Feature Flags (or Feature Toggles) is a way of working with code that allows teams to modify system behavior, without changing existing or deploying new code. It allows teams to handle deployments and new releases separately, and iterate rapidly.

Feature Flags vary by usage and context. Here we’ll look into three of the most powerful techniques that you can leverage:

Trunk-based development
Uncoupling deployments and releases
Living on your product (aka dogfooding)

When getting started with this approach, your product doesn't necessarily have to be complex. Also the solution you choose doesn't have to cover every possible use case, at least not from day one. Teams can use popular SaaS solutions, open-source projects or just start with a simple JSON file in their repo, so don't be intimidated by how much is possible. The most important thing is to change your thinking when it comes to writing and releasing new code.

Trunk-based development enables engineers to check unfinished features into the main branch and safely release them into production at any time. When working this way, teams develop code in short-lived branches that enable developers to merge and deploy safely. This technique helps cut the time it takes to merge new code by avoiding the big, complex conflicts usually associated with long-lived feature branches. Checking in code regularly guarantees that teams can move quickly, without obstacles. To do this, teams use feature flags to disable unfinished code until it's time for release. When the feature is ready, simply enable the flag and release the new feature into the world. This allows teams to separate releases from the act of merging code. It also means moving from long development cycles to a series of short ones. Instead of big changes being merged at once, there are now lots of small iterative changes that are merged and deployed often, preferably many times a day. This helps teams move faster and safer.

Being able to tie a particular feature to a particular user, or a group of users, allows you to verify your ideas cheaply and safely. Аlmost every new feature in Readymag is released for internal users first — so our design team can test them thoroughly. It is especially powerful if you use your own product in your daily work, because your beta testers are right there working alongside you. Get feedback fast and test your ideas before you release a feature for the general public.

Feature Flags allow easy experimentation. Often there is some idea, maybe a concept for a new feature or a smart way of improving existing code, that needs to be tested. Using Feature Flags allows developers to explore these ideas in a real production environment without fear of breaking something. Try things out and see what's working, and what's not, then decide how to act on it later. Combine this way of working with monitoring and product analytics, and you'll get a really powerful combo!

So let's illustrate all of this with a real world example. Recently we launched new subscription plans for Readymag. To implement them, we needed to adjust some parts of our application that control available features and what limits are set for each plan. This is where Feature Flags help immensely. First, we added a new Feature Flag to our system. From there we wrote new code and adjusted the existing behaviour behind the flag. We did this over the course of many iterations, continuously deploying new changes into production. For example, the front end looked like this:

Here, we conditionally render a new part of the UI. Existing code works as usual until the flag is enabled.
Since we have two different components in this example, the team working on this can safely work on a new interface without disrupting the existing flow.
Elsewhere in our system we would have code like this, implementing another part of this update:

Of course it is always a good idea to test your code, especially when using something as dynamic as Feature Flags. So we did just that:

When we were ready to launch the update, we just enabled this flag and the feature was rolled out. Not only did this approach allow us to merge and deploy code continuously, it also made it possible to enable new code branches in several services at once without coordinated deployments.

Here are some best practices around Feature Flags that we use in Readymag:

Feature Flags should have a short life cycle—they are used only before a feature is released, not to control long-term product behaviour.
Always ask yourself if it would be easy to delete a particular flag later.
Each Feature Flag is responsible for a single feature. It should have a name that is commonly understood.
All flags should have similar semantics: all flags enable something, they don’t disable features.
Sometimes it is better to duplicate code to ensure clean removal of the flag when the feature is released.
Flags can and should be used for experimentation and to verify hypotheses.

So, the next time you're battling with some exhausting merge conflict, or you find your team holding on to some code because it’s too early for it to be released, or you wish that your team could try out some idea but it’s too dangerous, try using Feature Flags. Solve your problem at hand, and hopefully change your whole product development cycle for the better.