English is, without question, the worst programming language ever created. It is not merely flawed; it is fundamentally unsuited for the reliable transmission of complex ideas. Anyone who has ever tried to communicate a non-trivial technical concept to another human being knows this instinctively. The ambiguities, the contextual dependencies, the endless opportunities for misinterpretation — English excels at all of them.

If you have spent any time in meetings, code reviews, specification documents, or even casual Slack threads, you have felt the pain. And if you have any background in mathematics, physics, or formal logic, the contrast becomes almost comically stark.

Precision: The Foundation of Reliable Computation (and Communication)

At its core, a good programming language is a formal system designed for unambiguous execution. Every valid program has exactly one meaning under the language’s semantics. A compiler or interpreter will produce the same behavior every time, assuming the same inputs and environment. This is not an accident; it is the entire point.

Mathematics and physics adopted formal languages for the same reason. When Newton or Leibniz developed calculus, they didn’t just wave their hands and say “the rate of change, you know, kinda like speed but for curves.” They created notation — symbols, rules of manipulation, axioms — that allowed precise statements like:

This expression has one, and only one, interpretation among those who understand the formal system. There is no room for “well, depending on what you mean by derivative” or “in my experience, sometimes it’s 2x plus or minus a bit.”

Physics follows suit. Maxwell’s equations in differential form are not poetic suggestions:

These are not open to “opinions-based” interpretation. Misunderstand a sign or a vector component, and your electromagnetic device will quite literally fail to function. Engineers and physicists spend years learning to think within these formalisms precisely because natural language is too sloppy for the phenomena they describe.

Formal languages exist because human natural languages are terrible at edge cases, scope, and unintended interpretations. We invented predicate logic, set theory, lambda calculus, and programming languages to escape the swamp of ambiguity.

English, by contrast, is the swamp.

The Many Ways English Fails as a Specification Language

Consider something as seemingly simple as a requirement: “The system shall process transactions quickly.”

What does “quickly” mean? Under 100ms? Under 500ms? Does it depend on load? On hardware? On network conditions? Is this a hard guarantee or a soft target? English offers no mechanism to distinguish these.

Now imagine trying to implement a sorting algorithm based on an English description:

“Sort the list in ascending order, but put the most important items first, unless they’re duplicates, in which case keep the original order for those.”

Good luck. Is “important” defined? What constitutes a duplicate? Does “original order” refer to stable sort semantics? English leaves all of this to intuition, shared context, and — inevitably — arguments in code review.

Real-world examples abound in software projects:

• “Handle errors gracefully” — Does this mean log them? Retry? Notify the user? Crash the process? Return a default value?
• “Make the UI intuitive” — Intuitive to whom? A power user? A complete novice? Someone from a different cultural background?
• “The cache should be consistent” — Eventual consistency? Strong consistency? What about partition tolerance?

These are not edge cases. They are the norm. Experienced engineers learn to translate vague English requirements into precise specifications, often using formal tools (user stories with acceptance criteria, UML, TLA+, property-based testing) precisely because English alone is insufficient.

Ambiguity at Every Level

English is ambiguous at the lexical, syntactic, semantic, and pragmatic levels.

Lexical ambiguity (multiple meanings for the same word): “Bank” can mean a financial institution, the side of a river, or to rely on something. Context usually helps, but in technical documents, context can itself be contested.

Syntactic ambiguity (parsing issues): Classic example — “I saw the man with the telescope.” Did I use the telescope to see the man, or did the man have the telescope? Programming languages avoid this with strict grammar rules and operator precedence.

Semantic ambiguity: “The function should return the largest value.” Largest by what metric? In what ordering? For floating-point numbers, what about NaN or signed zeros?

Pragmatic ambiguity: What is left unsaid. In a conversation between colleagues who have worked together for years, massive amounts of information are implied. New team members, or an AI trying to implement from a spec, have no access to that shared mental model.

Compare this to Python, often praised for readability:

def process_data(data: List[float]) -> Optional[float]:
    if not data:
        return None
    return max(data)

Even without types, the behavior is unambiguous to anyone who knows Python’s semantics. max([]) raises an exception, but here we explicitly handle the empty case. The return type hint further constrains expectations.

English has no equivalent of type hints, no compiler to catch inconsistencies, no unit tests for prose.

Why We Put Up With It (And Why We Shouldn’t)

English has undeniable strengths. It is expressive, flexible, and culturally rich. It can convey emotion, nuance, humor, and poetry in ways that formal languages cannot. Shakespeare didn’t write in lambda calculus for a reason.

But when the goal is reliable transmission of executable ideas — specifications, APIs, requirements, designs — those strengths become liabilities. Flexibility is another word for underspecification.

Anyone with real experience communicating complex ideas knows the pattern:

1. Write what seems like a clear English description.
2. Send it to a colleague.
3. Receive back an implementation that is technically correct but completely misses the intent.
4. Spend hours in discussion clarifying what was “obviously” meant.
5. Repeat.

This is why mature software organizations invest heavily in:

• Precise requirements documents with measurable acceptance criteria
• Formal methods (where the cost justifies it — e.g., aerospace, finance, medical devices)
• Contract testing, property-based testing, and exhaustive specification
• Code as the single source of truth, with comments used sparingly

The very existence of these practices is an admission that English is inadequate.

In physics and mathematics, we don’t tolerate “it’s approximately true, in the usual sense.” We define terms rigorously. We prove theorems. We build models whose predictions can be falsified experimentally. The precision of the language enables the precision of thought and the reliability of results.

Programming aspires to the same rigor. That’s why we have static type systems, formal verification tools like Coq or Lean, and languages with strong guarantees (memory safety, data-race freedom, etc.).

English remains the worst because it resists all such discipline. It evolves organically, embraces exceptions, and thrives on interpretation. It is a living, messy, human thing — wonderful for literature, conversation, and persuasion; disastrous for programming.

A Humble Remark

We don’t need to abandon English. We need to recognize its limitations and use better tools where precision matters.

Next time you write a technical specification, ask yourself: Could this be misinterpreted in a way that leads to incorrect behavior? If the answer is yes (and it almost always is), add precision — through examples, edge cases, invariants, or even pseudocode.

Treat English as a high-level, lossy compilation target rather than the final executable specification.

Because in the end, the computer doesn’t care about your opinions, your intent, or what “everyone knows” you meant. It executes precisely what you told it — in a real programming language.

And humans, despite our intelligence, are not much better than computers when the specification is written in the worst programming language of all: English.

We just hide our bugs better, and argue about them longer.

Draft date: 2025–08–25
Author: Charles Zhang
Tags: Divooka, Methodox, Entrepreneurship, Roadmap, Architecture

Many years from now, when power users, researchers, and historians look at this article, they will see how it all started and glimpse the vision behind our work.

Ah, vision — a fascinating subject, and a quality not appreciated by all. Like the ability to dream, to imagine, and to dwell in the realm of mathematics and technicality. For imaginative minds, it’s dangerous to wander too far; without standing on solid ground, one can hardly make real progress. Often, it pays to be hands-on.

Divooka is (or is becoming) a complete, general-purpose, high-level, multi-paradigm, flexibly typed, modern visual programming language/system, complete with package management, standard libraries, application frameworks, graph editors, IDE, CLI executor, code generator & compiler, derived frontend apps, examples, documentation, and accompanying tutorials and training materials. We’ve achieved the majority of this already, so it’s not an exaggeration to list them now. What’s more, there are still ideas I haven’t put into words.

It’s hard to do one thing well, and to achieve all of this with limited resources, we need a good strategy. Of course, the strategy itself is a secret I won’t share — it’s fairly simple, really, but requires determination and execution power. After a year since incorporation last July, it’s useful to review and recap what we’ve done and where we are.

In this article, I’ll focus on the period from January to August 2025, but to give a complete picture, I find it instructive to look back and highlight outcomes from last year and key lessons learned.

Early 2024

2024 was about the modernized inception of what Divooka is today.

Neo was reviewed a third time, and we managed to trim down most legacy code. It was time to think more broadly about the concept of “general-purpose visual programming,” rather than just a demonstration for data analytics. A new repository was created for modern development. Gospel was conceived.

Talks with investors and prospective entrepreneurs mostly confirmed that this subject is hard, and we learned there are countless low-code platforms in China. That is good.

A disagreement with a co-creator helped me settle the fact that we would definitely go desktop-first and worry about the web later.

The conception of Quadrinity and the flexible office software framework inspired me to quit my job and move forward.

July–Sep 2024

During initial incorporation, development was highly focused, and Divooka, though very simplistic, was a well-defined, easy-to-perceive single tool with only a handful of nodes. With Haopu’s help on plotting, it quickly looked like a handy little utility for data analytics — a subject matter we should continue to explore and focus on in the future.

At the same time, to prepare for public preview and an angel investor meeting, I spent a month making prototypes for many potential application areas, including experimental libraries and web use. Due to lack of sophisticated integration and completeness, I doubt these prototypes made as strong an impression as I hoped.

On the marketing side, the concept of a case competition was pitched during this time, but it never materialized later in 2024 due to slow progress on software completion and the dashboard library.

Sep–Dec 2024

With the promise of investor funding, I decided to expand operations and start hiring contractors to work on various aspects of the overall Divooka platform, including GUI design, website improvements, and preparation for first practical use. In a previous article, I mentioned that end users were unlikely to use Divooka directly during initial adoption. To elaborate:

1. Lack of comprehensive DSL libraries at this stage.
2. Overall complexity and learning curve as a general-purpose programming language.

While we could have focused on DSL, the second point made it unlikely to gain traction (given how unknown we were) and not commercially feasible any time soon. Thus, we needed more specific, tool-like, highly focused, direct end-user GUI applications.

For that reason, we published Fantasy Planet Painter. We also planned to publish Arcadia, but timeline issues prevented it.

It was during this period that we conceived what was previously known as “ZFA,” while “fighting” for the trademark of “Zora” in Canada. Due to delays with investment funding, personnel management, and other corporate matters, we didn’t make significant progress on the modern Morpheus framework or ZFA at that time.

In conclusion, during these busy four months, there was not much I would call technical progress. Most efforts were miscellaneous but time-consuming. I also learned it was better to take more matters into my own hands.

Jan–Aug 2025

January to August has been much more fruitful and productive, despite major distractions in January, May, and July. With help from Aaron, Allan, and ChatGPT — and without the communication burden of contractors and external collaborators — progress has been slow but steady. More importantly, I’ve had time to investigate highly technical matters and build foundational work.

The Web Summit in May and internal training from April to July helped us greatly polish the Neo graph editor, stabilize Neo’s internal serialization format, and establish Divooka for general-purpose use.

Ecosystem-wise, I’ve done plenty of investigation and prototype work on Python integration, build automation, code refactoring, and preliminary work on online services.

There has been extensive work on Neo and Neo-first features, including general GUI improvements, bug fixes, plugin framework enhancements, subgraph work, generics, lambda support, multilingual framework setup, procedural context, and other experimental work. Related to this is the improved Neo serialization format, which is becoming more robust and stable. We haven’t yet worked on package management. Although we are trying to make it DiDS-conformant, it’s still far from achieving a single final format.

DSL-wise, there has been initial work on Ol’ista, Glaze!, Slide Present, and Novella. Many utilities were also created for ChatGPT and GenAI services, including interfaces for Nvidia NIM, ComfyUI, and Hugging Face inference services. Different users have different demands, and it’s hard to focus on any specific library without a pilot project. While we do have internal pilot projects, they are large in scope and still require groundwork, so Divooka hasn’t yet played a significant role. I do want to seek external collaboration on this — but at the moment resources are constrained.

On the plotting front, as of early August, Aaron has made significant progress on the mid-level plotting API, making Divooka’s plotting library almost “self-sustainable,” able to meet a wide range of demands.

Although data analytics is arguably not our only focus, use case investigations have improved in-memory DB handling, refactoring, and preliminary libraries for PostgreSQL ingestion. One architectural challenge is expression interpretation: we decided long ago that, at least for data analytics, it’s not efficient to rely entirely on node interfaces — some coding is desirable. The main focus is SQL snippets through our in-memory DB library, though at times LINQ expressions and in-place C# scripting have been useful. However, concerns with the latter are robustness, error tolerance, predictability, increased distribution size, and future program export compatibility.

The data analytics API also faces the challenge of whether to focus on OOP or tabular data as intermediate formats. Sometimes one is more convenient than the other, which increases development costs to maintain both. Eventually, we will likely keep both but prefer exposing the tabular format in Divooka.

A more complete picture of “data analytics” in Divooka would extend into data science and machine learning. There’s plenty of research to do here, including choosing a foundational library, gradually building our own infrastructure, and developing graph-friendly, visual-programming-first APIs. This will have to wait until next year.

Summary

The most visible outcome is that Neo is receiving significant updates. On the programming language front, Divooka’s function libraries are growing as the language becomes more capable, flexible, and production-ready. Once we start working on package management, it will be more prepared for practical day-to-day use. However, package management requires a fully functional online service first.

Meanwhile, we are actively exploring more “direct-user-facing” applications, which I’ll discuss in future posts.

We could use a lot of help on DSL work, and that’s the plan as the foundations solidify and architectural decisions become clearer.

References

Wiki Entries on related subjects:

• Glaze!
• Novella
• Ol’ista
• Slide Present

DevLogs on Divooka/Neo progress:

• DevLog 2025801: Procedural Context Type
• DevLog 20250711: Flappy Bird in Divooka! (Sneak Peak)
• DevLog 20250710: Generics in Divooka
• DevLog 20250708: Procedural Context Visual Debugger in Divooka
• DevLog 20250619: Modularization Improvements
• DevLog 20250613: Ol’ista Web Framework
• DevLog 20250610: Plotting in Divooka
• DevLog 20250510 Dealing with Lambda
• Progress Share 20250509: Graph Local Lambda Calculus in Divooka

The Introductory to Visual Programming with Divooka Textbook:

• Access it online here!

Additional references:

• DevLog 20250805: Divooka Node Graph File Formats
• Public Roadmap
• State of Divooka

Glossary

• DSL: Domain-specific Library
• DiDS: Divooka Document Specification
• DiOS: Divooka Open Standards
• Gospel: The new, revived, modern incarnation of Parcel, gateway into Divooka; Now a new graph editor frontend for Divooka
• Neo: The Windows graph editor for Divooka
• Morpheus: The cross-platform GUI framework and graph editor architecture for Divooka
• Quadrinity: A way to perceive office suite software as a single framework consisting of multiple views, like Blender’s workspaces
• ZFA: Zora Frontier Architecture

Written by: Charles Zhang
Tags: Visual Programming, Developer Tools, API Design, Software Architecture, Programming Paradigms, NVI, No-Code / Low-Code, Programming Philosophy, Tool Economy
Target Audience: Software Architects, Engine and Tool Developers, Programming Educators and Curriculum Designers, Low-Code/No-Code Platform Researchers, Senior Developers interested in alternative programming models, Developers interested in visual alternatives to traditional code

This Part 1 focuses on raw API usage. A Part 2 will follow on Morpheus and its derivatives. This article offers high-level analysis and is not intended for beginners.

Abstract

Traditional programming uses text to represent program logic. Existing visual design platforms offer varying levels of programmability but generally focus on building specific kinds of applications. From a production-use perspective, Divooka represents a significant step forward in how users build and interact with software — by combining tool-building, data handling, and program logic under a single, coherent interface. This unified approach aims to deliver a substantial productivity boost.

Overview

If we already have a really good library — just as we have high-quality commercial software — does it still matter what language or environment we use?

In theory, it shouldn’t. In practice, it absolutely does.

Pretty much everything imaginable already exists for C++, often under GNU licenses. But that doesn’t mean a Python, C#, or Java developer can easily access or use those resources. Even when libraries are available for a target language, usage may not be straightforward. Licensing, API design, and documentation all come into play.

Still, let’s imagine we have a well-written, freely accessible, multi-language-bound, well-documented, and easy-to-use library. Does it then matter how we use it?

That leads us to the core question:

If we already have a really good API, why not just use it in C#, Python, C++, Lua, or Pure?

The Proof of Concept

To explore this, we can approach the question from three distinct perspectives:

1. The end user
2. The program designer
3. Everyday tool development and sharing

From the end user’s perspective, assuming the final deliverable is a polished CLI or GUI tool, it typically doesn’t matter what language was used — as long as the interface is well-designed. Case closed.

From the program designer’s perspective, building anything sophisticated involves significant “dry” work — debugging, iteration, architectural decisions. Productivity depends largely on the quality of the debugger and IDE, and again, it’s not strictly tied to the programming language.

But from the perspective of everyday tool use, the question becomes more subtle. What do we mean by “everyday tools”? Broadly speaking, we mean:

1. Tools built quickly to solve practical problems within days
2. Tools that are easy to share and use by others
3. Tools that are easy to iterate, improve, refactor, and eventually package as full software
4. Tools that are maintainable — so that months later, we can return and still understand what we were doing, without extensive documentation effort

To solve (1), you need extensive libraries.
To solve (2), you need solid dependency and packaging mechanisms.
To solve (3), you need simple syntax and easy refactoring.
To solve (4), you need expressive, self-documenting code — or better yet, self-explanatory program design.

It’s in this third category — everyday tools — that Divooka stands out. The features baked into Divooka’s graph editor enable rapid development without sacrificing performance or scalability. The editor itself proves how smoothly things can run with minimal setup: just open a graph document, and it works.

The NVI

In Divooka, the primary mode of interaction is the Node Visual Interface (NVI) — distinct from both CLI and GUI paradigms.

Each node represents a functional unit, and the connections represent program or data flow. Unlike CLI, NVI offers “autocomplete” visually — everything is made explicit through connection and layout. Unlike a GUI, an NVI is composed entirely of nodes and avoids complex syntax structures.

At the base is a node canvas, and programs are built using what we call node-driven design — a pattern that breaks software into node blocks, each representing a compositional or procedural component.

The main disadvantage of NVI compared to text-based programming is space inefficiency: nodes occupy screen real estate, reducing information density. But this is offset by improved readability: the visual layout shows the exact dependencies between functional units — something much harder to grasp in linear text code.

NVI becomes more powerful when it supports:

1. Subgraphs — Logical groups of nodes encapsulated into single blocks. This is more compact than plain functions or classes and more intuitive than managing multiple files.
2. Extensible node visuals — Nodes can be customized for specific data. For example, a Table node can offer compact entry for 2D data, reducing friction.

The Scripting Interface

At its core, the NVI exposes functionality in two ways:

1. Nodes represent standalone functional units in a Divooka document.
2. A framework parses the interconnected nodes and derives behavior from the graph structure.

The key is interface availability — file operations, media I/O, math routines, etc.

The first use case is covered well by scripting languages like Python, Lua, or Jupyter.
The second — interpreting a structured node graph into dynamic program behavior — is where traditional languages fall short, often requiring large, specialized frameworks (e.g., Streamlit for Python).

With Divooka, the same graphical program often needs no changes at all. A simple toggle in the host environment can completely redefine how the program behaves.

Frameworks like Glaze, Novella, Ol’ista, Slide Present, and App Builder (all part of Divooka Explore except App Builder) rely heavily on metadata — information not defined on the graph, but embedded in the document and interpreted by the host system.

This separation — code in the graph, behavior defined by metadata — creates a powerful, data-driven model that enables reuse, variation, and flexibility.

On the Matter of Libraries

Not all useful features are readily available via libraries. And even when they are, compatibility issues, licenses, platform differences, and interoperability challenges often make reuse hard or impossible.

At Methodox, we actively author and maintain a curated library set — toolboxes optimized for Divooka. This represents a major investment, ensuring that as Divooka grows, users have an expanding, well-integrated set of native components tailored for node-driven environments.

Summary

From a scripting standpoint, Divooka may appear unremarkable: libraries are still authored in native code, and Divooka simply provides an interface layer.

But methodologically, Divooka offers a profound shift in how we build and interact with programs. It’s as different as using a natural-language model to co-write your software.

Divooka is a high-level, GUI-native, NVI-first programming system. Our belief is that this new format can significantly enhance productivity, readability, and maintainability by making programs smaller, clearer, less error-prone, and more intuitive.

Methodox Technologies, Inc. — officially registered in Ontario at the end of July last year — has now been around for nearly a full year. Time has passed neither too quickly nor too slowly, moving along steadily as it always has. The biggest difference between running a company and doing personal side projects, in my view, can be captured with a comparison between passion and professionalism: when you do something out of passion, you choose based on interest; when you do something professionally, you commit regardless of mood or preference, working methodically toward clear goals and standards — day or night, rain or shine.

To put it more concretely, the difference lies in quality control. As someone with an engineering background, I’m not particularly gifted at self-promotion. What I can do — and do most naturally — is focusing on making a good product. Some friends have asked where the motivation comes from. Truthfully, I’m not entirely sure either. But like clockwork, I still wake up at 6:30 a.m. every day, ready to work.

When I first started working on Divooka, I didn’t envision it as a fully-fledged programming language. I wanted it to be general-purpose, yes — but not necessarily from the standpoint of a programming language. The goal was more about decoupling the functionality from its environment, enabling it to run directly from the command line, and making the library design flexible enough to work beyond our immediate domain.

Initially, the biggest problem I wanted to tackle was how to replace Excel. There are many ways to go about that — because Excel’s greatest strength is also its weakness: it’s too powerful and flexible, which means it often lacks structure. And that chaos is what we wanted to bring order to. The first step was to build something on top of the spreadsheet concept — adding structure and rules, using something like object-oriented thinking to enable users to visually edit and link spreadsheet data.

Had we stayed on that path, the Divooka interface today would probably look more like floating spreadsheet windows — similar to Apple’s Numbers — instead of the visual node-based editor you see now.

Back in 2019, I had already started exploring the idea of using general-purpose programming for GUI building. My approach then was more framework-oriented: tools that could generate UI wrappers based on flowcharts. These weren’t new languages, but auxiliary features to make diagrams more reusable.

In early 2024, we also explored two major directions: graphic annotation and online collaboration, inspired by modern design tools like Figma and Google’s cloud-based productivity suite.

The ability to build complete applications wasn’t something I initially envisioned — it seemed too ambitious for what started as a personal side project. But going full-time removed that ceiling. It gave us room to think bigger.

One of the most natural and promising directions for Divooka is visual app development. Unlike traditional text-based languages, Divooka was built as a graphical, extensible environment from the start. Its own development environment is a Divooka app — one that is, in principle, programmable with Divooka itself. That vision is still in blueprint form, and full realization will take time.

From a business perspective, the experience of leading a team from late 2024 into early 2025 has been mixed. On the plus side, offloading certain tasks helped reduce some pressure. On the downside, with our current financial constraints, it’s been hard to find help we can fully rely on — which, perhaps, is just reality.

Teamwork through outsourcing introduced its own challenges. Choosing the right people is tough. Even highly capable partners don’t always deliver the expected results. Interestingly, ChatGPT and other large language models played a strange but useful role in this phase — mainly by helping with research and code scaffolding.

There’s a pattern I’ve noticed: even when working with contractors, I end up defining the architecture and interfaces, and much of my time still goes into coordination. Once you’re past the prototyping phase, iterations are limited, and results vary. In a similar way, large language models tend to produce “one-shot” outputs — either useful or not. But if I’ve already built the structure, the autocomplete results I get from an LLM often rival what a junior outsourced developer might provide.

In that sense, I’d much rather work closely with people over time — collaborating, communicating, and refining a shared workflow. That’s where real teamwork becomes meaningful.

Early on, development followed a pretty rigid schedule — when it was just me, with no meetings or other obligations, daily goals were clear and straightforward. But by mid-year, things were shifting constantly. On the one hand, that brought flexibility, and led to a number of unexpected developments, especially in product direction. On the other hand, such reactive planning made it harder to estimate timelines. A case in point: our “first full version,” originally scheduled for release this February, will likely be delayed until next year.

But as mentioned earlier, even the definition of what qualifies as a “first full version” has evolved dramatically.

In many ways, my approach to this company mirrors how I ran projects in university. First, I’m still the main driver and implementer. Second, I remain cautious when it comes to collaboration. Over the years, I’ve come to understand the Economy of Scale in a deeply personal way — not in terms of wealth or headcount, but in how accumulated skills and better tools dramatically boost my individual productivity. In this age of AI, that effect is more visible than ever. Contrary to popular belief, knowledge — not just capital — is the primary engine of productivity.

That said, if you do have capital and a great team, collaborative scale can still achieve amazing things.

One of the more surprising (though perhaps not shocking) aspects of this journey has been the mix of encouragement and skepticism I’ve received. Support has mostly come from peers in the professional world, while more traditional voices — old friends from university, family members — have tended to be more doubtful. Though, of course, there have been exceptions in both camps.

This kind of reaction isn’t often talked about on social media, but I think it’s worth reflecting on.

First, people naturally fear what they don’t understand. Second, those closest to us — friends, family — end up becoming supporters in one way or another, whether they intend to or not. Third, when it comes to values and personal incentives, people respond differently to attempts to break convention — especially where money is involved.

At a few conferences, I’ve had the chance to talk with other founders. Their motivations, strategies, and philosophies run the full spectrum. Some of the most frustrating folks are those who throw around the term “AI” without substance. (We too fell into that trap at one point, admittedly.) But these experiences — moments of confusion, attempts to find clarity — have opened up my view of the world far more than reading philosophy books or binge-watching TV shows ever did.

Looking ahead, I see three key challenges:

1. Finishing development and releasing the first full version of the software.
2. Creating a complete educational system around it, ensuring product coherence and knowledge accessibility.
3. Marketing and forming partnerships, while keeping the company sustainable.

2026 will be a demanding year. We’ll need to maintain development speed while trimming back unnecessary administrative tasks. We want to move with precision, but not become overly cautious. The path forward requires boldness, care, grounded execution, and avoiding the lure of shortcuts. That’s something I need to keep reminding myself.

Technical debt is like refusing to fix a leaking roof because it’s raining — only to forget about it when the sun comes out.

In this article, I’d like to share some thoughts on computing in professional environments, especially from an engineering perspective. These are based on over 18 years of experience in software and insights gathered from three years of observing workflows and speaking with veterans across industries — financial services, banking, retail, and engineering alike. One challenge with this topic is people are so familiar with existing practices, they may not see things as a problem — until they are shown a solution, but the solution may be complex.

The financial industry is used here as an example — not because it is uniquely flawed, but because it is highly relatable and emblematic of issues in many complex corporate environments. The emphasis here is on computing infrastructure, though the discussion touches on organizational and human factors, which are often inseparable in real-world implementations.

As an engineer, I strive for system coherence and comprehensibility. Complexity is natural and even necessary. Complication, however, is a human failure — and preventable. This piece is not about client-facing technologies, but about the internal systems, processes, and philosophies that make a corporation function, scale, and evolve.

Summary

This article is long, so here’s the TL;DR:

• Avoid most commercial cloud services unless absolutely necessary.
• Minimize hierarchies.
• Use Azure DevOps (ADO) for task management (there is no equivalent that offers the same streamlined workflow).
• Provide scriptable, reusable interfaces for data analysis and reporting.
• Use SQL (raw or wrapped) throughout the data stack for ETL.
• Avoid “business intelligence” solutions (like PowerBI) for anything mission-critical.
• Never use Excel in production.
• Invest in tailored tools for core business functions (e.g., custom accounting platforms).
• Consider interactive simulations or serious games for training.
• Design your enterprise as API-first, not “AI-first” (AI-first is often just a buzzword).
• Prefer locally deployed AI models, ideally developed in-house.
• Underpinning all of this is a core belief: existing practices are broken, and a new paradigm is needed.

While Divooka (our own platform) embodies this philosophy, this is not an requirement. Any platform that addresses the same core issues is welcome — though in years of searching, I’ve yet to find one that does.

Motivation

For both individuals and teams, the drive for faster workflows and better tools is ultimately about insight. In complex business environments, speed allows for rapid iteration, which in turn drives productivity. Higher productivity then lays the groundwork for greater efficiency and clearer decision-making. This is just as true for corporations as it is for individuals. But iteration only works if tools are adaptable.

Hence, the efficiency of problem-solving is directly tied to the efficiency of developing custom internal tools. If you ever find yourself thinking “it would be really nice to have this and that feature,” and you then have to wait for someone else to implement it, iteration suffers.

For large institutions — national pension funds, tier-one banks, or multi-national insurance firms — this goes beyond tooling. You need:

• Layered access control
• High-frequency analysis
• Security
• Training pathways for new hires (e.g., interns)

Data accessibility — delivered in real time through well-documented, API-based endpoints and tracked under version control — is the foundation of true analytical agility. Real-time feeds ensure every dashboard or machine-learning model works from the freshest data; API interfaces enforce consistent, self-service access patterns; and versioning of schemas, transformations, and pipelines guarantees reproducibility, rollback capability, and a full audit trail.

At the same time, security isn’t just a matter of firewalls and encryption keys; it must be baked into every process and every team’s mindset. That means clear ownership of data assets, defined approval workflows, regular training on best practices, and a culture where raising and resolving security concerns is as routine as running your daily reports. Security is not just a technical problem — it is a cultural and process problem.

Top-down visibility is also essential. Leadership should be able to trace any issue through systems with a single click. If they can’t, the system has failed — not because of complexity, but because of poor design.

And while executives don’t need to understand every implementation detail, they must understand the principles — and more critically, invest in education both for themselves and for entry-level employees. A longer-term view builds resilience, retains talent, and enables innovation.

Making the Best of Existing Tools

Cloud computing has made off-the-shelf infrastructure appealing — but this convenience comes at a cost. Over time, the lack of control becomes a liability, especially at scale. High-performing organizations must eventually invest in internal capabilities.

> It is always cheaper in the long run to take matters into your own hands — if you can attract and retain technical talent.

Additionally, code review must be mandatory for anything related to automation — whether for internal dashboards, accounting tools, or production pipelines. Not just for QA, but for education and sustainability.

In software development cycles, a healthy time division might look like this:

• 1.5x Analysis/Modeling
• 1x Development
• 0.5x Code Review
• 0.5x QA

Financial organizations should also standardize on microservices to simplify endpoint access and reduce cross-system coupling.

For any company that uses the word “agile” unironically: Azure DevOps (ADO) remains the gold standard for work item tracking, integrated version control, testing, and pipeline automation.

A critical warning: Beware the proliferation of internal dashboards. While it may seem counterintuitive, the tendency to build highly visual dashboards is a distraction from what matters — reliable APIs, scalable infrastructure, and actual automation.

Based on experience, “API-first” saves 80% of the effort in the long term compared to building UI-first.

The Solution

We can only solve problems in ways we are best at. I am a software engineer, and that’s how I model, analyze, and tackle challenges — by making software. It’s also often helpful to keep in mind the human factors.

The Peer Developer Model

Financial analysts are de facto computing professionals. Any work at scale is computational. And yet, most organizations underinvest in bridging the gap between analysis and implementation.

There are two solutions:

1. Invest in training analysts to code (bite-sized, structured, mandatory).
2. Assign companion developers — dedicated engineers working side-by-side with analysts.

This is similar to how civil engineers complement architects. The developer’s role: implement, optimize, and review code, leaving analysts free to model and interpret.

A junior-to-mid-level OOP developer (familiar with C-family languages) costs ~$100K and can support 2–3 analysts effectively. This model reduces headcount while increasing productivity.

The Integrated Big Picture

Eliminating redundant tech stacks is the single most powerful way to reduce technical debt. In most organizations, essential functions are scattered across dozens of tools, each requiring specialized training.

The solution is to build reusable internal libraries, APIs, and tooling ecosystems around key functions (data ingestion, transformation, reporting, access control). And yes, this requires investment — but for a firm managing billions, it’s well worth it.

Open-source solutions often provide better APIs and lower long-term cost. But the goal isn’t cost reduction per se — it’s control, efficiency, and resilience. Cost savings will follow.

The All-Rounded Technical Analyst Model

Divooka is our vision for what this looks like in practice: a unified computing platform combining:

• Enterprise-grade C#
• SQL-dominant ETL pipelines
• Python’s rich data science ecosystem
• A modular, plugin-based architecture
• Low-code/no-code visual programming
• Fully local, one-click deployment

The result are self-contained, auditable, maintainable pipelines that cover 90%+ of analytical needs, with fewer components and shallower learning curves.

This abstraction allows analysts to become full-stack operators — no longer needing to juggle five tools for one task.

The winning stack: C# + Divooka + Python + PostgreSQL + ADO + GitHub + microservices. For dashboarding, maybe Grafana, though it’s not perfect.

Related Topics

These toolsets raise natural questions about hiring and training:

* What kind of analysts should we hire?
* How fast can we get them productive?

From an engineering standpoint, we want people with structured programming experience — even in entry-level roles. No one flies a plane without a license; why run production data systems without proper coding fundamentals?

Traditional programming bootcamps won’t suffice. But a modern analyst can get up to speed in 3 months — if trained with the right curriculum: Excel + SQL + Divooka (Yes, Excel is still needed for practical reasons). That’s all you need for 80% of the analytical workload. The rest can depend on aptitude.

Conclusion

This article outlines an ideal — but attainable — vision for computing in complex industries.

These problems can be solved with or without technology. But solving them well requires the right mindset, structure, and investment. Every organization has unique needs, and solutions should be iterative, adaptive, and people-centered.

If any part of this resonates with your experience, I’d be happy to continue the conversation.

Changelog

• 20250509 Rev 001: Initial draft.
• 20250520 Rev 002: Refine ideas.
• 20250609 Rev 003: Adjust wording and refine ideas, staging for publication.
• 20250620 Rev 004: Polishing.
• 20250624 Rev 005: Update tags; Improve formatting. Enhance clarity of statements.

See also

• [Review] 20250620: The Plan to Supersede Excel

What he didn’t know is that this is just like one of my other projects: there is strong motivation, an implementation plan, and progress being made. Like my other personal projects, I mostly work on it alone, and I don’t engage early with users. Like any other project, it may fail, of course. In fact, based on what I know — most startups fail.

What’s different this time, and something he didn’t realize, is that the project has an integral business component. I’ve quit my previous job and am now working full-time on it for steady progress. Engagement with users and the market is a planned step — when the time is right.

I think it’s time to talk about my engineering process — and it’s time to talk about The Big Design concept.

Engineering Design Process

The course that nurtured me the most (and surprisingly, most of my peers disliked) at university was Praxis, taught by the controversial Professor Foster and a well-reputed professor whose name I now forget, in 2013 during my EngSci class. It was very high-level, very abstract (in a conceptual but not mathematical way) — exactly the kind of information that appeals to me.

In a nutshell, the engineering process has roughly 3 to 5 stages, depending on one’s approach. I now realize the process they taught was more of a “waterfall” model than the “agile” approach used ubiquitously in software development today. Here are the component stages:

1. Ideation — Identifying problems, brainstorming solutions, etc.
2. Conception — Identifying constraints, selecting evaluation criteria, choosing a solution, etc. I also include research in this stage. In agile, this may already be where we start prototyping.
3. Implementation — Development, prototyping, etc.
4. Validation — Testing, feedback, etc.
5. Iteration — Communication, adjustments, etc.

The process taught in class turned out to be overly simplistic and theoretical — like most things taught in school — so I won’t focus more on it.

My Engineering Design Process

During my first year or two at university, I approached personal projects using roughly that model. But I placed heavier emphasis on the conception stage. I believed that a strong conception was more than halfway to implementation. That was before I learned about agile methods, and long before I encountered the creative design process.

One frequent problem: I’d bail out halfway through the project because I had spent too much effort producing dozens of pages of design documents and got lost during implementation. A related issue was that, due to limited skills, a lot of designs looked good on paper but couldn’t be accomplished by me.

As I gradually learned about agile, my focus shifted to early prototyping. But then, another problem arose: I spent too much time prototyping, features became overwhelming, and again the projects couldn’t be finished — this time because the scope ballooned beyond available time and resources.

The biggest project I finished back then was Dream Editor — over 20K lines of code, three rewrites, completely developed from scratch. It took me 9 months with barely any sleep and contributed to me failing first-year EngSci. A key lesson was distilled into one word: obsession. Obsession was necessary to push projects to completion. As it turns out, it’s a useless program now — I have far better ways to do things — but the lessons were learned.

As time became more precious and the complexity of projects increased — especially during my time at OTPP, working on countless developments — I greatly refined my agile process into a more balanced conception–development–evaluation loop.

But it wasn’t until I worked at BBI that the process truly came together. The missing piece was Azure DevOps as a task management tool, replacing all my earlier, clumsy attempts at building custom tools. There’s a lot to say about Azure DevOps — it’s not just about typing task descriptions and linking things. It’s a mindset. It’s a methodology.

Then something changed me forever.

The Creative Design Process

I didn’t have a name for it until recently. But I knew it was different the moment I began engaging with it.

I was pretty intense at university — I read a lot. None of my friends believed it, but reading 600+ page textbooks was normal for me. Despite looking new, I’ve digested most of the hundreds of textbooks on my bookshelf — they’re well-maintained because I love books. That trait, though, caused serious problems with deadlines — like exams. I failed exams.

Then Ray told me: “Don’t try to understand things — just get them done.” That was hard for me, but eventually it got me an A in my anthropology paper. And of course, I eventually graduated, thanks to Ray’s advice.

I remember when I was an intern, Ali would casually ask, “What’s the most important lesson you’ve learned so far in life?” I forgot what I said, but his answer was: Focus. Jerry and I laughed — it sounded like some kind of feel-good nonsense. Ali didn’t elaborate. Later, before we drifted apart, I once told him I had too much to learn. He said he had lots of saved books yet to finish, but he wasn’t worried. I still didn’t get it.

People who know me know I’ve been working on Project Nine for 12 years. So far, it hasn’t produced much — at least not visibly. But two years ago, I had a creative burst and shared some exciting results with my personal manager, Ellote. I eventually had to pause due to time constraints, but the burst was enabled by a few things:

1. A refined creative and production process
2. A focused pipeline I call “VBA”
3. An emphasis on implementation over design

Later, I joined CGPB to learn from masters in Montreal. Their teachings confirmed this process: ideas and even concepts matter very little. They change a lot during implementation. Design is not on paper — it’s emergent through the creative process. There is no single “design” step in such a process; it’s refined gradually, through iteration and only through iteration.

I’m sure this wouldn’t work for building bridges or airplanes — but maybe that’s how those start, too.

I call this The Creative Design Process.

The Big Design

The Big Design is an abstract concept. It generalizes the engineering design process and is based on a belief:

If it’s part of the design, and the implementation follows, it will be done.

The early form of the concept was shown in the note archive above.

I told some friends: a few of the “surprising” projects I did weren’t surprising to me. It’s hard for them to believe — but it’s true — because they were all part of the design.

When something is part of the design — when you’ve factored it in from the beginning, when it’s implemented as an integral part of the process — if you’ve taken all factors into account, and continue refining the concept as new information comes in, and finish the implementation — it must achieve what you intended.

Conclusion

It’s been 12 years since I started university — and 12 years since I started Project Nine. The most valuable lessons we’ve learned are about the limits and capabilities of ourselves. We learned what is controllable, what isn’t, and what needs more work. That experience is invaluable — it enables us to make better predictions, better evaluate situations, and build plans that accommodate future challenges.

I think that’s why I enjoyed working in risk — anticipating what might happen that others might overlook, and most importantly, planning for it.

On the topic of risk: like I said, most startups fail — and we’ve planned for that. In fact, with Methodox, as I operate it now, there won’t be any kind of “bankruptcy” failure — it would be more like a soft exit. We’ve prepared for that possibility from day one.

As for the exact plan — that might be a story for another time.

So maybe life isn’t a surprise after all.

Written by: Charles Zhang
Tags: Web Summit, Startup, Vancouver

This article reflects my personal experience and opinion. I attended Web Summit with the goal of evaluating the event and learning as much as possible. If I sound opinionated — it’s likely because I’m speaking from direct experience.

The 2025 Vancouver Web Summit concluded on Friday, May 30. For a three-day event (or four, if you count the opening), it didn’t feel as “busy” or “enriching” as the 2025 San Jose NVIDIA GTC — despite our booth day and a high volume of interactions. That said, in terms of sheer traffic, we saw meaningful results: increased LinkedIn follows and website visits. This kind of measurable impact is rare without a physical presence at tech events.

Event Organization

• The founder’s talk could have been more engaging and focused.
• There were no complimentary snacks, coffee, or giveaways for general attendees — a surprising miss for an event of this scale. The “Food Summit” trucks were limited, though some offerings were delicious.
• The Mayor’s enthusiasm in welcoming Web Summit was appreciated, though the tone occasionally felt as if the city was overextending to host it.
• The event leaned heavily into a business networking environment. I’ll expand on this further below.
• Many attendees were job seekers, which didn’t align well with the startup/partnering focus of the event.
• The conference had diverse topics but lacked a unifying theme or headline announcements, making it feel less cohesive compared to events like NVIDIA GTC or AWS re\:Invent.

Observations and Business Insights

Our booth day on Friday was busy, though we didn’t get the opportunity to pitch to the general audience. I did attend a few pitch sessions, and most presenting startups had established products, customers, or revenue. They appeared significantly more “market-ready” than we are, and it reinforced a valuable point: as with VCs, traction and revenue are key to standing out.

We observed that startups with interactive demos or physical setups drew the most attention — and I am glad we prepared some video recordings along with live demo for our software.

Pitching Takeaways: Immediate Appeal Matters

One key theme across Web Summit and the AWS x NVIDIA startup event: pitches that address familiar, non-technical problems resonate the most.

Examples with strong “immediate appeal”:

1. AI-enabled autonomous toddler stroller
2. Underwear that boosts sperm quality
3. Smart AI-enhanced bra
4. AI-powered back pain seat pad

Mid-tier:

1. NFC-enabled digital business card

Harder-to-grasp but high-potential ideas:

1. Bacteria-based paint with environmentally friendly manufacturing process
2. Visual programming systems aimed at boosting developer productivity

The Opening Event

Held Tuesday night, the opening event felt underwhelming. The visual setup (crate-like backdrop) was eye-catching, but no food or drink was offered to general attendees. Only startups had access to coffee, which felt misaligned with the event’s scale.

The CEO’s welcome speech lacked energy, and overall, the program felt flat. Music and trailers were fun at first but quickly became disconnected from the tone. The immediate transition into a panel with Gary felt abrupt and missed an opportunity for a celebratory kickoff.

Opening Talks — Highlights from Gary’s Panel

Despite the subdued opening, Gary’s insights on AI and technology were a highlight:

• Granting too much power to immature AI systems is risky.
• LLMs are “autocomplete on steroids” — not true intelligence.
• AI-generated code is quick to produce but hard to debug: we’re often fixing code we didn’t write.
• Prompting feels like “prompt and pray,” and the trial-and-error approach introduces inefficiencies.
• Time spent verifying AI-generated content can outweigh the benefits, especially for tasks like world-building.
• Traditional algorithmic systems remain superior for traceability and reliability.

Further observations:

• GPT-5 was renamed 4.5 — performance expectations weren’t met.
• Grok 3 is 10x more expensive than Grok 2, but with diminishing returns.
• LLMs may not scale to general intelligence as hoped.
• AI industry valuations are likely inflated — driven by hype over real returns.
• A survey of 7,000 companies found AI had limited impact on bottom-line results.

BlueSky & Decentralized Social Networking

Jay Graber (BlueSky CEO) offered thoughtful insights on AT Protocol and decentralized, user-first platforms:

• Offers open APIs for data, feeds, and identity
• Introduces community-powered moderation
• Small team (25 people) supporting over 35 million users — a strong proof of scalability
• Operates as a “public benefit” company, not ad-driven
• Monetization via subscriptions and feed-sharing
• Especially strong traction in science, niche, and developer communities

It’s worth experimenting with the technology and we may explore how Divooka can share content into niche BlueSky feeds to find more aligned communities.

Final Thoughts

• I heard from a university contact that some ALPHA startups received free admission and even airfare — this is worth looking into for future events.
• Despite Web Summit’s global reputation, I found NVIDIA GTC more impressive in content, even at reduced scale.
• The AWS x NVIDIA pitch event was a letdown — minimal food, no meaningful connections, and unanswered follow-ups.
• The true highlight was the Web Summit pitch competition: well-organized, engaging, and a great conversation starter.
• Night Summits felt too business-focused, with crowded venues and no complimentary food. Only the final night was more casual and enjoyable.
• Vancouver’s setting is breathtaking. Even though many talks were just average, the opportunity to meet startups, gain exposure, and learn from others made the trip worthwhile.

Overall, Web Summit is a strong platform for early-stage startups to get visibility and connect. I’d recommend attending — especially if you’re pitching. That’s where the event truly shines.

We are going to attend Web Summit as a startup this year. Our VP, Edison, found out about Web Summit, and after an interview, we got in. Apparently, Web Summit is quite big — it used to be called Collision and was hosted in Toronto. The overall theme of Web Summit used to be Web3. Nowadays, of course, everything is about AI.

For $700, they will give us ALPHA status, a booth for one day, and three free tickets. The booth turns out to be very small and located in a crowded area with hundreds of other startups. Initially, we were told we couldn’t bring much marketing material, which turned out not to be the case once on site. We are allocated the last day of the conference. In this article, I will share some of my experiences attending conferences as an entrepreneur. (Eventually, we will see that the most successful startups are those that have other interesting presentation materials — e.g., cool demos and physical setups.)

Soon before Web Summit, many companies began trying to sell candidate lists by sending us emails, and even more found us on LinkedIn for business opportunities — selling services to us, that is. Among them were some very persistent vendors. We had already spoken with a few, but follow-up was inconsistent, while new representatives continued reaching out. It’s not surprising, but still amazing to see so many businesses offering similar services — digital marketing, software consulting, and so on. Much of the outreach came from international service providers.

Before attending, I was under the impression that the event would be somewhat informative — maybe as much as NVIDIA GTC, with lots of educational content. However, the online communities (e.g., WhatsApp groups) largely involve companies looking to pitch and promote themselves.

Verdict (Some Impressions/Reflections):

• A noticeable amount of promotional outreach. Some advertisers even offer contact information of attendees — the only value of which to us right now is tracking the growth of the attendee pool, from 5,000 in April to over 15,000 in May.
• The excitement dies out quickly when the first two of the three main startup events (Pitch, 40 Words, Mentorship) turn out not to be relevant to us. The mentorship program, however, is fairly easy to get into. As it turns out — much like appealing to VCs — having a solid business with existing revenue is the key.

We’re looking forward to seeing how the event unfolds.

It’s been almost a year since I founded Methodox and began full-time development on Divooka. It’s certainly a risky endeavor compared to the more secure job of Risk Analyst at OTPP. I’m not getting paid, there are no vacation days, and ever since Haopu left, I haven’t enjoyed “Friday Game Afternoon” alone as much. Some people believe in what I did and what I do; some just support me as a friend. Gradually, as we piece everything together and build more robust software, people are beginning to appreciate what Divooka can do — and how freeing the visual interface can be. That’s only a fraction of the power of visual programming as a paradigm, and I think it’s imperative to dig a bit more into my vision as we get closer to meeting a broader audience at Web Summit in Vancouver this May. You may get lost, but I hope this article provides enough insight for those who try to understand.

Visual programming is about allowing one to see the execution of code in a visual manner by providing a handy (and ideally beautiful and efficient) GUI for constructing a program, while reducing complexity as much as possible. At its core, the goal is to get things done in a reproducible way. Fundamentally, it’s not very different from coding in text or using natural language to instruct a machine — it’s all about interface. Many years ago, one would build a website by hiring a contractor; nowadays, one can just click a few buttons or speak, and get similar results. Whether or not it’s sufficient to deliver an entire real-time application or full-stack solution is another question. That’s the goal of Divooka.

There is another way: if all the services or functions one ever wants are already packaged by some super nice provider, and we are content. We all know that’s false, and things get ugly fast whenever we want to customize existing solutions that claim to get lots done for you. My ultimate goal is to be able to trivially build, analyze, and simulate a city. To do that, I need simulators, distributed agents, databases, geometry processors, metrics analytics, real-time feedback, online services, a visualization engine — among other things. I need to be able to do it effortlessly and efficiently, with high customizability, and at the lowest possible cost, running on the most powerful consumer machine available, and practicing the same setup thousands of times. At some point, spending more money and more resources will no longer be feasible — and I am not a billionaire yet. To really get things done, one almost always needs to do it themselves. That illustrates the demand for better tools.

Divooka is a fourth-generation, high-level, multi-paradigm visual programming language. There’s a lot behind “fourth-generation” and “high-level,” so it might be a bit hard to comprehend at once. In a nutshell, it means you don’t need a lot of steps to get something big done. More technically, it means the APIs we expose automatically take care of resource acquisition, setup, management, and bookkeeping for you — so the user only needs to think about what they want to do, not how to do it. A close resemblance is Wolfram’s Mathematica, which unfortunately feels like a half-finished toy these days. This is very different from asking an LLM to do things for you — as an interface, the behavior of all functions we expose is well-defined and clearly documented, and functions should just work out of the box. Unlike an LLM (or a human, for that matter), whose behavior may differ slightly every time you invoke it. Such predictability is key to automation.

The “multi-paradigm” part is more abstract, but essentially it means “you can program however you like.” More specifically, we are focused on functional, logical, and OOP paradigms. All of these aim to model the problem at hand from a “true-to-the-problem” perspective rather than a “true-to-the-machine” one. The expressions are closer to the problem domain than to machine language. Supporting different paradigms is imperative, since some problems are solved more easily when formulated differently. In fact, the whole idea behind Turing completeness is to “find a more suitable representation” — understanding the problem is halfway to solving it.

The world is already using visual programming everywhere without realizing it, and without a full, general-purpose, well-recognized visual programming language. Platforms like Power BI, LangChain, ComfyUI, Unreal Blueprint, Blender, Houdini, Rhino Grasshopper, etc., all have visual or block-based editors that let users “connect pieces” to form a plan, a workflow, a program — or express ideas in general. It’s ubiquitous in computer graphics and entertainment industries. Outside those fields, most visual diagram platforms are more illustrative and serve as visual references — they cannot be executed. I used to use Draw.IO a lot to organize ideas, but I always felt unsatisfied that after brainstorming a plan, I still had to implement it in Python, C#, or whatever language. Others, like Unreal Blueprint, are very sophisticated but require C++ to extend and only run within the Unreal environment. I feel it’s a huge waste of talent — it could have been far more ubiquitous.

Visual programming is one of those things that’s tricky to grasp, but once you get over the hump, it’s flat terrain — everything feels obvious. That initial barrier is the cost of building a functional GUI. In fact, we tried to finish our cross-platform GUI implementation toward the end of 2024, but so far we’re still stuck with the WPF implementation of the Divooka graph editor. There are a lot of moving pieces when building a UI, but the fundamental concept is straightforward: you have some blocks (or “nodes”), and you connect them somehow (using “wires” or “connections”), and things get executed one by one.

With an infinite canvas, one can easily lay out their thoughts. And once that’s done, it’s a fully executable program. It’s a beautiful paradigm. To get all this working, we need libraries — existing building blocks that represent atomic operations in visual format. Traditionally, services are exposed as C++, Python, JavaScript, C#, or Web APIs — now we just need to encapsulate all of those to be usable in Divooka. Many services are already being “forced” in this direction — like LangChain moving to LangGraph. It’s exactly the same thing as visual programming, just not explicitly marketed as such because they don’t aim to be “general purpose.”

The way I see it — there should already be a general-purpose platform where developers, vendors, and service providers simply add their own libraries on top and contribute. Then users only need to learn one tool — in this case, Divooka — and use everything within it. That’s hard to do in existing programming languages, not because of lack of demand, but because of the challenge of learning and agreeing on a single platform to expose all APIs. We see this already — people are wrapping all kinds of APIs for Unreal Blueprint, which serves as a benchmark for Divooka because it’s a solid implementation of many concepts.

Technologies, like all things, will always reflect personal preferences. I have friends who still don’t use Git for version control. Divooka won’t be the only option out there for quick, efficient, accessible visual programming. Marketing will always be a huge challenge — video coding and low/no-code tools will continue to be a major distraction. But what I intend to build is a platform that can stand the test of time — starting with local deployment, unburdened by online services, and gradually fostering a community and robust ecosystem for all useful tools, with as many open-sourced or source-available components as possible (or at least open specs). So people can trust it, understand it, study it, and feel confident relying on it.

The problem is the same kind as with MCP (see earlier article): adoption. Organizations that aren’t already API-driven or programmable will not embrace Divooka, regardless of what kind of programming language or “next big thing” it is, because the cost of change is simply too high. It’s never just a specification/protocol/language and done. Someone must push it — hard — and start using it at scale. Hence, the not-so-obvious but evident solution: we at Methodox must take on this challenge ourselves. I believe AI may help accelerate adoption, but for most people and companies, it won’t matter much. The core idea is that some kind of unified system must be established — and we cannot rely on third parties (who may go out of business or change their policies) for that.

Since many will draw immediate attention to it — the discussion so far isn’t affected in any substantial way by the advent of LLMs. An unsolved problem remains unsolved until a breakthrough specifically addresses it. Take data analytics, for example. Before Divooka, we had Excel — great for quick, ad-hoc data gathering, but it falls short when doing repeated analysis or working with changing source data (e.g., number of rows or fetching from databases). SQL, on the other hand, is a great functional programming language that many overlook, misuse, or underutilize in analytics — its lack of adoption partly stems from its tight coupling with formal databases, where creating views can require privileges analysts don’t always have. Even with AI assisting, the ad-hoc and on-demand nature of analytics remains — and Divooka is a perfect bridge for chaining SQL commands visually. This is doable in any custom-built visual programming platform, but general applicability wouldn’t be possible if Divooka weren’t a general-purpose language.

But the most important part — often overlooked — is that Methodox, and I, need to thrive, become the major force using it, evangelizing it, improving it, showing the world what it can do, influencing others with it, building it, protecting it, and maintaining it. The future of visual programming languages — given the absence of any other company taking on this responsibility — lies directly with Methodox and with me. While I’m alive, the one project I will finish is Project Nine, and I envision Divooka as the solution. The more urgent question is: how fast can we deliver? I will spend the rest of 2025 working on the DSL and cross-platform support. Hopefully, we’ll get a second angel round off the ground, and by next summer, Divooka v1 will be ready. Then we’ll see what business opportunities await Methodox.

That’s the broader vision. I look forward to the day when the prominent DSLs (domain-specific libraries) are ready, and I can simply show you what Divooka can do — and what it has become.

I always knew I wanted to create something big. It’s both fortunate and unfortunate that I was born into an ordinary family and had an ordinary life. Fortunate, because I can focus on smaller problems — no robotics or flying motorcycles or large AI systems yet; unfortunate, because frankly, when compared to all those big firms on LinkedIn with large capital to spare, what I do doesn’t immediately look that cool. My eventual goal is to create an entire world — but we’ve got to start small, and I believe what I solve is more foundational than those with bigger hype. Quitting my job and starting a company is new for me, though.

Everyone has different affinities. The choice to start one’s own venture versus staying comfortably within a group is a personal decision — so personal that it often ties to who we are and what we believe in. The first thing to figure out is what to do first; then how to do it. I don’t worry that much about why, for reasoning is self‑deceptive.

The Productivity Problem

As an experienced programmer, I know just enough about the practical boundaries and limits of various tools. The differences between C#, JavaScript, and Python go beyond syntax, and there are things that seem very intuitive in production software but are embarrassingly absent in API forms. It’s a matter of a few clicks to curve‑fit a dataset in Excel, but doing the same in Python requires trial and error. It’s even trickier to search through the entire email inbox and take automatic actions like exporting all email attachments to a folder.

The gap between the GUI world and scripting is bigger than anyone has imagined. Without good visuals, beginners are intimidated; without programmability, things cannot scale. Yet many problems are simply not solved or solutions not immediately accessible — take tagging files as an example. Lots of dedicated software let you tag things in a GUI, but there is no easy way to go further or start programming those tags.

Anyone dealing with data or solving problems at scale (and repeatedly) is inherently facing programming challenges and must become a good programmer for efficiency. When generative AI became available, people began to see hope: GenAI is a portal into a realm of problems that was previously inaccessible — now, with text, we can invoke them as functions and get things done. But AI is not there yet, and I doubt it ever will be, because really useful systems are so sophisticated that even 365 billion‑parameter models struggle to handle them. Still, practical matters cannot wait.

Incorporation and Business Administration Matters

Prioritizing what to do was and still is a challenge. As a single‑person corporation, I am simultaneously R&D, production, IT, marketing, accounting, and occasionally client service and legal departments. The officially logged tasks number in the hundreds, and unofficially, I have quite a few dozen TODO lists here and there. This is very different from a large‑scale, long‑term personal project: I do have personnel to train and delegate work to, and contractors to synchronize progress with — plus plenty of events to prepare for and attend. There is no hard deadline for anything, but there is cash outflow, scheduled meetings, expected product‑delivery milestones, and — did I mention time is ticking? We still have no income.

A corporation has many government‑set deadlines, especially if you are hiring or need to file GST/HST. T4s are due by February each year, and GST/HST returns typically by the end of March. Then there’s the big T2 tax return due in June, and you must bucket your expenses and revenue appropriately based on tax categories. It’s important to keep all the physical receipts. As a bonus, you can claim an ITC on the GST/HST paid in expenses.

Hiring someone takes a lot of effort and resources. It’s not just that you need to match and pay EI and CPP contributions. Bookkeeping costs can be high — you need to remit either quarterly or monthly. I recommend doing that after each salary payment. Even if you’re not hiring anyone, it’s important to file a nil remittance!

Nothing personal, but I’ve learned some unpleasant lessons:

1. Dealing with lawyers, consultants, and accountants might feel like a pleasant conversation, but afterward the process always leaves a bad feeling in your gut, your wallet, and your conscience.
2. Never pay contractors until the job is done — better yet, don’t fall for cheap quotes; pay by the hour.
3. Managing people takes lots of time, and honestly, despite all my attempts, I still feel it’s more efficient (time‑, quality‑, and money‑wise) to do things myself.

But Why, or Is It the Right Time?

It’s hard to believe in oneself and stay true to the vision when people are constantly asking about the things they care about most. Money never really concerned me that much, for I’ve seen it all, spent it all, and never really possessed that much anyway. It’s the situations that arise that make you wonder: am I doing the right thing — for our product, for our company — never for myself?

You know I mentioned entrepreneurship is personal. I chose it because it’s what I want to do (Methodox and Divooka and everything to come), but it’s hard to confront investors and potential users when there’s no scale of operation, no revenue, no user base, and no released product yet. That last point is really the critical one — it’s a chicken‑and‑egg problem: without entrepreneurship we couldn’t spare the time to build the product, and without the product there could not be a business (there’s nothing to sell). So someone has to take the risk, and there are so many startups doing all kinds of weird things — you can see it and feel it all if you visit any startup section at a tech summit. Do they all really believe in what they do like I do? Do they truly feel an imperative to take matters into their own hands, or did they just have a brilliant stroke of insight, an eye for business opportunities, or plenty of time and fortune to spare?

Every business succeeds in its own unique way. A good solution solves people’s problems; the best ones do it indirectly. The tools and techniques that benefit me most are those I never thought of myself. Existing problems almost always already have a solution — in most cases they’re just people problems — so innovation should instead focus on creating systems that are new and unthinkable, ideally verifiable and foolproof so as to be usable.

Anyone can think of and make a flying car; anyone can think of sending humans to Mars. Certainly I give credit to those who make it happen. But I am more inspired by electric motors, version‑control systems, games possessing Turing completeness, the first touch screen, and the first consumer VR headset. That’s true innovation. That was unthinkable before. For me, that’s the business worth entrepreneuring for. Whether we succeed is a matter of will and luck, and hopefully I’ll get crazy rich — then I can buy a city, build a university, and solve real problems in this world rather than merely entertain the masses. It’s a dangerous fine line between idealist and dictator.

It’s all about self‑fulfillment for sure, and the process matters as much as the result. That’s my way of entrepreneurship.