From 20 To 100 Million Developers

Yesterday, I spent time at the home of a successful banker in Singapore who taught himself how to code in his 50s. He was joined by his top data scientist and his CTO from two of the ventures he invests in. A part of his success can be attributed to his appreciation of how rigorous science and math can be applied to finance and innovation. It’s nice to see someone enthusiastically join the ranks of the roughly 20 million developers building software today, and it’s making me wonder what will help us increase this number to 100 million developers in the coming years. His convictions and enthusiasm on three questions caused me to reconsider my own positions. That is to say:

1. How can no/low code platform (NCDP) be used to build (important) software?
2. When will LLMs make it possible for (almost) anyone to create software?

I’ll address those questions here in part so that I can share this with others and to see how my opinion might change over time.

1. No/low code tools (revisited)

I have written on the fallacy of “no-code” tools in Jan 2021, where I discuss

1. that you are probably a coder already (e.g., Excel or GSheet)
2. examples where NCDP work, and
3. what matters most is productivity of the product builders.

Consequently, today we already have plenty of no/low code tools in use. But are those tools what venture capitalists would invest USD 100M+ to turn into unicorns? Most likely yes, but let’s unpack this a bit.

1.1. NCDP for simple jobs or prototypes

NCDP can already be used to make stuff people want. I decided to try OutSystems because I learned that NTU used it to create an app used by 20,000 students (captive audience) and that some serious investors like KKR have poured USD 800M+ into this beast of a startup. I gave it a shot for 30 minutes to see how far I could get:

1. I created an account
2. Then I installed Service Studio locally
3. Followed the tutorial, which let me create something from scratch
4. It prompted me to import an Excel as my database (clearly a common use case for their target audience)
5. I found a single sign-on (SSO) module on the Forge
6. And then the app crashed and I had to force quit it in MacOS
7. I reloaded, and found that I now had two modules, one for SSO and one with my prototype (without SSO)
8. My time was up but I can imagine how after another hour I might have something up and running

Conclusion: I can’t conclude that OutSystems would not work. On the contrary, it looks interesting for those who are ready to try something different. But it is not clearly better/faster/cheaper than using a more mainstream stack that millions of people use. The NTU bus app seems like something that would traditionally take 2-3 months to build and USD 50K in budget, including everything. After that, I’d imagine maintenance to be one part-time engineer who might charge a few hours a month to maintain, update, support, and train (MUST) people, and less than USD 1K a month on a platform as a service like AWS. To be truly innovative, I’d love to see NCDP enable schools like NTU to build bus apps for USD 5K, or even USD 500.

1.2. Find competent people

For a startup that has raised millions of dollars, or enterprises who are spending similar amounts on technology, I think the most important first step is to find people who have a good understanding of how to make things people want. These are the individual contributors that will be responsible to analyze, dream, design, architect, implement, maintain, update, support and train others (ADD AI MUST). I have yet to meet someone who has a good understanding of how to do this well that doesn’t know the syntax of a few programming languages like Python, Javascript, or R.

1.3. The right tool for the job

That doesn’t mean that after you raise millions of dollars, you shouldn’t use a NCDP. It might very well be a good decision. However, you should only do so if you have found someone with deep understanding who thinks that using an NCDP is the right tool for the job. The practitioner with tacit knowledge of how to ADD AI MUST, is the person who makes this choice.

I’d venture to say that a pretty significant number of startups in Silicon Valley (e.g., Y-Combinator backed startups) who are getting started in 2024 will not use a NCDP and instead will use a stack that resembles the following:

• React.js
• Next.js
• Tailwind CSS
• Django
• PostgreSQL
• GraphQL
• Azure Kubernetes Services (AKS)
• GitHub and Actions
• Cypress
• Snyk
• New Relic
• Mixpanel
• SonarQube
• Jira
• Visual Studio Code
• Azure OpenAI

To illustrate the point, as of Dec 2023, React.js, Next.js, Tailwind CSS, and Django have respectively 217K, 116K, 75K, and 75K stars on Github. This may be speculative, but my guess is that the number of proficient developers in each is likely to be 5-20X as many as the stars it has on GitHub, as many developers use these technologies without necessarily starring their repositories on GitHub. So 2M-4M million React developers globally is likely directionally correct. By the time we go from 20M to 100M developers, I find it plausible that NCDP will also increase usage/adoption by 5-10X.

If we include educational coding platforms, then MIT Scratch (by the Media Lab and Lifelong Kindergarten group) has amassed over 100 million developers already. This wide user base shows the potential of using block-based coding as a gentler learning curve as opposed to typing each letters individually. One could argue that it blurs the line between NCDP and traditional coding.

2. Large language models make it possible for anyone to code

Developers are not gatekeepers, quite on the contrary, they are usually are eager to teach those who are willing to learn. So why do so many people fail at learning to code proficiently? I love to see my kids use chatGPT to learn how to code. I check their history and they don’t blindly copy paste. The questions they ask teaches them fundamental concepts in a way that reading the docs or searching Google/Stackoverflow wouldn’t do as effectively.

2.1. A brief hitory

We have seen a lot of exciting development (pun intended) over the last 400 years to empower humans to use computers as obedient and dedicated helpers who not only enable things like eCommerce, supply chain logistics, and digital communication, but also to entertain us with video games, social media, and TV streaming. As long as we feed them electricity and provide them a cool/dry environment, they will perform as they are instructed to.

And it’s easier now than it has ever been before. Here’s a (very brief) history of this remarkable evolution:

1642: Invention of Blaise Pascal's Mechanical Calculator (Pascaline).
1833: Ada Lovelace begins work on Charles Babbage's Analytical Engine.
1890: Development of punch card technology by Herman Hollerith for the US Census.
1943: Development of ENIAC, the first general-purpose electronic digital computer.
1949: Introduction of Assembly Language with the EDSAC computer.
1972: Development of the C Language by Dennis Ritchie at Bell Labs.
1974: Introduction of the Altair 8800, considered the first personal computer.
1989: Tim Berners-Lee invents the World Wide Web (Web 1.0).
1991: Linus Torvalds releases the first version of the Linux kernel, marking the Free and Open Source Software Movement.
1995: Release of Java by Sun Microsystems, popularizing Object-Oriented Programming.
1998: Founding of Google.
2004: Popularization of the term "Web 2.0," marking a transition to interactive and social web experiences.
2005: Creation of Git by Linus Torvalds; GitHub founded in 2008.
2006: Introduction of AWS by Amazon, initiating the Cloud Computing and Platform as a Service era. Also, creation of Hadoop for big data processing.
2007: Introduction of the iPhone, boosting mobile app development.
2008: Launch of Stack Overflow, exemplifying crowdsourcing in software development.
2014: Introduction of smart contracts by Ethereum, a significant step towards Web 3.0 and decentralized web applications.
2018: Introduction of advanced Large Language Models like GPT-4 by OpenAI.
Expected Future Development: Quantum Computing, an ongoing research area with significant potential.

So I think we should celebrate how LLMs make coding more accessible.

2.2. Making good stuff still requires effort

An LLM might get someone up and running very quickly similarly to a NCDP. But it comes with a warning: it still requires effort. I’d conjecture that not knowing how to code has less to do with intelligence and more to do with willingness to sustain effort over time.

So someone who was willing to put effort 5, 10, or 30 years ago, is only going to see the result of their effort increased today. Additionally ADD AI MUST forms a collection actions that are best performed as a team. As the number of people on a team grows, so do the number and the length of meetings. A rough approximation is that 1 on 1 meetings on a team will grow as a triangular series, until the point where people have no time work or communication breaks down.

Team size	Num meetings
1	0
2	1
3	3
4	6
5	10
10	45
20	190

2.3. Productivity gain

In addition to that, making software is creative knowledge work. Unlike manufacturing or services, where the amount of repetitive mechanical or repetitive cognitive work increases linearly with the number of people performing the work, creative work is more multiplicative between individuals, and much harder to estimate linearly. For instance, a poor performer might actually reduce the total amount of work that a team can accomplish. On the other hand, strong team members might multiply their strength.

Imagine that an “ok” performer can create X units of work. A “good” performer might create 2X during the same time. A great one, 10X. And an outstanding one 30X or more. On the other hand, someone who is a complete beginner might create exactly 0X if they keep asking for attention (for a time, until they learn).

It’s important to point out here that X is not a clearly/cleanly defined dimension. It certainly does not equate to the number of lines of code, for instance. To architect and implement a given feature, an outstanding developer might write fewer lines of code, in less time, with fewer bugs, with better maintainability and documentation, with more appropriates names, and with a better run time performance.

The good news is that I think LLMs have a positive impact on everyone, and the most efficient performers will have the greatest absolute benefits, but the smallest relative one in percentage, and the benefit is linear. Here’s a table to illustrate the point numerically, where W stands for work.

W without LLM	Team of 5 W	ΔW with LLM	W with LLM	Team of 5 W	Team of 5 ΔW
0X dev	0X team	⬆️ 0.5X	0.5X dev	0X team	⬆️ 0X
1X dev	1X team	⬆️ 1X	2X dev	32X team	⬆️ 31X
2X dev	32X team	⬆️ 2X	4X dev	1KX team	⬆️ 1KX
10X dev	100KX team	⬆️ 3X	13X dev	371KX team	⬆️ 271KX

This model needs to be calibrated/validated to represent reality. But the implications, if the model is true, are important to consider:

1. An LLM will help a complete beginner go from 0X to 0.5X almost instantly. That is remarkable. But a team of five complete beginners, who don’t learn, will still produce no useful work despite the LLM.
2. A team of “ok” performers without an LLM don’t produce much (presumably they never ship anything useful and never get anywhere), but with an LLM they have a fighting chance and could improve their performance by 3,000%. That’s huge!
3. A team of “outstanding” performers were already producing an outstanding 100KX of unit of work, and they improved by 300%. By far the greatest improvement in absolute value, but less in relative value to a team of “ok” performers.

In other words, if this is true, then:

1. The war for talent is well and alive, and great/outstanding performers are key to making stuff people want.
2. The number of teams that can ship useful products is increasing.
3. The greatest benefit, in absolute value, is captured by the few.

Word of caution: while useful as a conceptual tool for a casual blog post, this framework can easily be misinterpreted or misapplied. Please don’t. It shouldn’t be used to evaluation of individual developer contributions, which are more complex and multi-dimensional, or to estimate the time it takes a given team to complete a task!

2.4. Productivity cap

This raises another interesting question around productivity for creative work. If the task is to lay a brick wall or to pack and ship packages, then productivity can be measured using a single dimension (e.g., number of bricks or items/boxes packed/shipped). Creative work is harder to capture. Can creative knowledge work be narrowly defined as number of users or revenue? That’s what venture capitalists sometimes have to rely on for lack of better metrics.

For a lot of applications, the amount of work required is not necessarily in the 100,000Xs. Coming back to the bus app for NTU, this may well have been accomplished by team of two good people over 10 weeks (e.g., (2 * 2) ^ 3 * 10 = 640X). On the other hand, a team of 5 10X devs equipped with LLMs can now produce an equivalent of 371,000X units of work. Does that mean they could produce 500 NTU bus apps, or produce 1 in 10 weeks / 500 = 1 hour? Does that even matter or make sense? Of course not. But for some applications (e.g., developing GPT-4), it probably does make sense. Each product feature requires a minimum effort to architect and implement, which can vary by several orders of magnitude.

The bottom line is that while it won’t make everyone a coder, it might propel us quickly to 100M developers worldwide. This is all fantastic news for innovation on earth, as long as it is done ethically and safely.