“Software and cathedrals are much the same — first we build them, then we pray.”
— Sam Redwine
A few years back, my wife and I moved from Silicon Valley to Napa, California. We quickly became friends with our new neighbors, many of whom own boutique wineries, restaurants, and tour companies. Among them was James, who had been running personalized wine tours across Sonoma and Napa Valleys for over a decade. He had devised a unique technique of discerning a guest’s wine palate merely by posing a few well-crafted questions. This tactic ensured he could wow his clients with every winery visit he orchestrated.
About a year before we met, James decided to expand his business by selling his wine tours online. This venture required a tailored website and some automation. James hired a seemingly competent software firm that quoted a two-month timeframe for $25K. James took a leap of faith and secured a $100K loan against his house to fund the project, earmarking the excess cash for promotional activities. However, as two months rolled into three and four, the software was yet to see the light of day.
Meanwhile, James realized that the success of his business required additional features. The software firm used this as an excuse to demand more money and time. To keep the project going, James had to raise an additional $250K from friends and family under a personal guarantee. Finally, six months and $200K later, the long-awaited website was ready.
As the new system went online and started taking orders, James quickly discovered that the software could only handle a limited volume of orders. Also, as he learned later, many users got stuck during checkout without anyone realizing it. It was apparent to James that the software required more work, and he also had a few improvements in mind for streamlining the tour booking process. The engineering team quoted a whopping $300K for the job. James sought a larger development shop, and they proposed a complete rewrite of all software for $400K. They argued that the existing code was poorly structured, did not support the necessary traffic volume, and was expensive to maintain. James couldn’t afford this. By the time we met, he was stuck with crappy software and never expanded his business as planned, while owing a large sum of money to the investors and the bank.
Once James discovered my background in software development, he fired a barrage of questions at me. James couldn’t comprehend how seasoned professionals could underestimate the budget so badly, why software development for his seemingly uncomplicated business came with such an exorbitant price tag, and if the software firm conned him into forking over more money than was necessary. Ultimately, he wanted to know if I could help him navigate this predicament and, if so, how much time and money would it require.
This was hardly the first time that I heard those questions. I began coding at the age of twelve, and I’ve been building software, large and small, for four decades ever since. Throughout my career, I met numerous individuals like James — feeling disheartened, financially challenged, and on the brink of abandoning the dreams of their lives.
Software engineers are no conmen. If you ask an experienced developer to estimate an implementation of a well-defined algorithm, take their numbers and multiply by the factor of 3x to adjust for their natural optimism. Junior developers’ estimates are likely to be way off the mark, as the lack of experience makes them overestimate their abilities (known as the Dunning-Kruger effect).
However, engineers are no experts in business matters in general and even less so in the context of the venture they are hired to automate. When you create an informal high-level overview of the solution you want to build and give it to an engineer, you reasonably expect them to use their common sense to fill in the gaps. However, things obvious to you are rarely obvious to the developers. Every time they resort to using their intuition, they make invalid assumptions that invariably backfire. For an engineer to do a good job, they need a very formal specification that covers all the details and leaves no room for interpretation. Creating such a detailed spec is time-consuming and expensive, making it impractical to the point where only a handful of companies end up having one. This is the main reason for the recent proliferation of no-code development tools that allow business people to create software directly, without involving engineers. Unfortunately, while no-code tools are handy for creating a proof of concept, they are generally inadequate for building enterprise-grade software.
Providing developers with all the necessary details upfront is exceptionally challenging for a non-technical entrepreneur. Gaps in the specification lead to costly design iterations. While hiring an experienced solution architect can help, early-stage startups rarely employ one due to high costs, difficulty finding the right one, and lack of understanding the need. Good architects don’t exactly grow on trees; they are a rare breed. Unlike programming, software architecture isn’t formally taught in school, and engineers can only learn it without professional guidance (if interested, my book, Become an Awesome Software Architect, is available on Amazon). Without the right architecture, your software could serve as a proof of concept or even a minimum viable product but will fail to carry the business forward in the long term.
But even the most skilled architect in the world can’t solve all the problems. There is a cancerous tumor plaguing software development, rooted in the engineering mindset. Developers are taught to focus squarely on building properly functioning software, but that alone isn’t enough. Software must also be maintainable, meaning it can be easily understood and fixed by anyone, not just the original developer. Additionally, it must be adaptable to accommodate new business requirements. Neglecting maintainability causes lengthy, costly, and risky rewrites.
Most productivity tools, such as programming languages, integrated development environments, software frameworks, and AI code generators, are designed with the same mindset: assembling a working solution in the shortest time possible, with total disregard for maintainability. For instance, the most revered engineering methodology, Object-Oriented Programming, leads to a decline in maintainability by several orders of magnitude. Popular programming languages offer so many ways of coding the same algorithm that each engineer develops their personal programming style, resulting in code that others find hard to work with. Some engineering leaders stifle this harmful freedom of self-expression by creating coding conventions, only to eventually realize that their team spends more time enforcing the self-imposed constraints than doing useful work. Others turn to low-code frameworks to visually organize the development process, and often lose their top developers who, oddly, associate their creative freedom with typing code as plain text into an editor.
As James sat in front of me, eagerly awaiting my response, I took a moment to weigh my options. Throughout my career, I’ve developed a plethora of productivity tools. I experimented with my own visual designers, programming languages, integrated development environments, and virtual machines, to help me iterate faster on various business ideas. I wanted to move from a proof of concept to a minimal viable product to a full-fledged production system quickly, without breaking the bank or having to rewrite the software in the future. By the time I met James, I had already created a comprehensive toolset for the job. While not yet productized, it proved highly useful, enabling me to build complex software with exceptional speed and quality.
My approach recognizes that mainstream programming languages and tools are fundamentally flawed. Code or no-code, they aim at defining HOW the final solution must function, including the looks of the user interfaces and the flow of operations. This results in a significant investment of time and effort to design screens and develop business logic, while subsequent changes in business requirements invariably lead to massive modifications across the entire code base. In contrast, my tools allowed me to define WHAT the solution must do, i.e., a formal specification, leaving it to the machine to figure out the HOW on its own, from user interfaces to business workflows. Think of it as a no-code development based on radically new principles.
Long story short, I agreed to fix James’ predicament. It was a relatively easy task. With my tools, I had his entire system fully operational in production in just a few days. It was a simple gig, but it made me realize how much common good I can do by sharing my tools with others rather than keeping them to myself.
The statistics of software development are horrifying. Tiny projects succeed 61% of the time, medium-size ones get an 18% chance, and the success rate of large enterprise solutions is a mere 6%. Here, success means that the end customer is using the resulting solution in production, the project time is within 10% of the target, and the project cost is within 10% of the target (more details are in the Standish Group CHAOS Report).
Try answering a rhetorical question: would you ever hire a builder for your dream home when the chance of succeeding is 6%? Yet, we do it all the time when we build software. Gartner’s research shows that U.S. businesses in 2020 lost $2.1 trillion due to poor software quality, while technical debt reached $1.3 trillion (technical debt refers to the amount of money companies would have to spend if they ever decide to address all known bugs and deficiencies in their code). These staggering numbers mean far more than faceless economic losses. Behind them are shattered dreams, financial hardship, tremendous stress, and countless lost jobs.
This is why I created RISHON, to revolutionize software development. It layers a symbolic AI over the previously described approach. The AI’s role involves comprehending the specifications (the “WHAT”), resolving any missing or conflicting information (doing the job of a skilled solution architect), and determining all the operational aspects (the “HOW”). The specification changes as the business grows and evolves, and the AI adapts accordingly.
I fully expect RISHON to revolutionize the way early-stage startups operate. No longer will proof of concept be discarded, and the development of a minimum viable product will no longer come with a hefty price tag. Scaling and changing software will become a seamless and cost-effective process, allowing companies to achieve product-market fit much faster and with less risk. Startups will no longer waste investment money on technology that requires a complete overhaul in just a few years. Angel and institutional investors would enjoy reduced risks and more efficient use of funds by their portfolio companies.
Currently, nine out of ten startups fail. I fully expect RISHON to change this statistic, and pave the way for many great ideas previously held back by financial and technological constraints to see the light of day.
By the way, we are actively seeking design partners who create new solutions for their clients from a clean sheet, and those developing SaaS offerings. Together, we can improve RISHON’s capabilities while boosting your profit margins tenfold. If interested, please apply for early access (click on Early Access in the site's menu). For investor relations, email us at ir@rishon.com.
As always, I’d appreciate hearing your thoughts. Please feel free to connect with me on LinkedIn.
Many thanks for taking the time!
About a year before we met, James decided to expand his business by selling his wine tours online. This venture required a tailored website and some automation. James hired a seemingly competent software firm that quoted a two-month timeframe for $25K. James took a leap of faith and secured a $100K loan against his house to fund the project, earmarking the excess cash for promotional activities. However, as two months rolled into three and four, the software was yet to see the light of day.
Meanwhile, James realized that the success of his business required additional features. The software firm used this as an excuse to demand more money and time. To keep the project going, James had to raise an additional $250K from friends and family under a personal guarantee. Finally, six months and $200K later, the long-awaited website was ready.
As the new system went online and started taking orders, James quickly discovered that the software could only handle a limited volume of orders. Also, as he learned later, many users got stuck during checkout without anyone realizing it. It was apparent to James that the software required more work, and he also had a few improvements in mind for streamlining the tour booking process. The engineering team quoted a whopping $300K for the job. James sought a larger development shop, and they proposed a complete rewrite of all software for $400K. They argued that the existing code was poorly structured, did not support the necessary traffic volume, and was expensive to maintain. James couldn’t afford this. By the time we met, he was stuck with crappy software and never expanded his business as planned, while owing a large sum of money to the investors and the bank.
Once James discovered my background in software development, he fired a barrage of questions at me. James couldn’t comprehend how seasoned professionals could underestimate the budget so badly, why software development for his seemingly uncomplicated business came with such an exorbitant price tag, and if the software firm conned him into forking over more money than was necessary. Ultimately, he wanted to know if I could help him navigate this predicament and, if so, how much time and money would it require.
This was hardly the first time that I heard those questions. I began coding at the age of twelve, and I’ve been building software, large and small, for four decades ever since. Throughout my career, I met numerous individuals like James — feeling disheartened, financially challenged, and on the brink of abandoning the dreams of their lives.
Software engineers are no conmen. If you ask an experienced developer to estimate an implementation of a well-defined algorithm, take their numbers and multiply by the factor of 3x to adjust for their natural optimism. Junior developers’ estimates are likely to be way off the mark, as the lack of experience makes them overestimate their abilities (known as the Dunning-Kruger effect).
However, engineers are no experts in business matters in general and even less so in the context of the venture they are hired to automate. When you create an informal high-level overview of the solution you want to build and give it to an engineer, you reasonably expect them to use their common sense to fill in the gaps. However, things obvious to you are rarely obvious to the developers. Every time they resort to using their intuition, they make invalid assumptions that invariably backfire. For an engineer to do a good job, they need a very formal specification that covers all the details and leaves no room for interpretation. Creating such a detailed spec is time-consuming and expensive, making it impractical to the point where only a handful of companies end up having one. This is the main reason for the recent proliferation of no-code development tools that allow business people to create software directly, without involving engineers. Unfortunately, while no-code tools are handy for creating a proof of concept, they are generally inadequate for building enterprise-grade software.
Providing developers with all the necessary details upfront is exceptionally challenging for a non-technical entrepreneur. Gaps in the specification lead to costly design iterations. While hiring an experienced solution architect can help, early-stage startups rarely employ one due to high costs, difficulty finding the right one, and lack of understanding the need. Good architects don’t exactly grow on trees; they are a rare breed. Unlike programming, software architecture isn’t formally taught in school, and engineers can only learn it without professional guidance (if interested, my book, Become an Awesome Software Architect, is available on Amazon). Without the right architecture, your software could serve as a proof of concept or even a minimum viable product but will fail to carry the business forward in the long term.
But even the most skilled architect in the world can’t solve all the problems. There is a cancerous tumor plaguing software development, rooted in the engineering mindset. Developers are taught to focus squarely on building properly functioning software, but that alone isn’t enough. Software must also be maintainable, meaning it can be easily understood and fixed by anyone, not just the original developer. Additionally, it must be adaptable to accommodate new business requirements. Neglecting maintainability causes lengthy, costly, and risky rewrites.
Most productivity tools, such as programming languages, integrated development environments, software frameworks, and AI code generators, are designed with the same mindset: assembling a working solution in the shortest time possible, with total disregard for maintainability. For instance, the most revered engineering methodology, Object-Oriented Programming, leads to a decline in maintainability by several orders of magnitude. Popular programming languages offer so many ways of coding the same algorithm that each engineer develops their personal programming style, resulting in code that others find hard to work with. Some engineering leaders stifle this harmful freedom of self-expression by creating coding conventions, only to eventually realize that their team spends more time enforcing the self-imposed constraints than doing useful work. Others turn to low-code frameworks to visually organize the development process, and often lose their top developers who, oddly, associate their creative freedom with typing code as plain text into an editor.
As James sat in front of me, eagerly awaiting my response, I took a moment to weigh my options. Throughout my career, I’ve developed a plethora of productivity tools. I experimented with my own visual designers, programming languages, integrated development environments, and virtual machines, to help me iterate faster on various business ideas. I wanted to move from a proof of concept to a minimal viable product to a full-fledged production system quickly, without breaking the bank or having to rewrite the software in the future. By the time I met James, I had already created a comprehensive toolset for the job. While not yet productized, it proved highly useful, enabling me to build complex software with exceptional speed and quality.
My approach recognizes that mainstream programming languages and tools are fundamentally flawed. Code or no-code, they aim at defining HOW the final solution must function, including the looks of the user interfaces and the flow of operations. This results in a significant investment of time and effort to design screens and develop business logic, while subsequent changes in business requirements invariably lead to massive modifications across the entire code base. In contrast, my tools allowed me to define WHAT the solution must do, i.e., a formal specification, leaving it to the machine to figure out the HOW on its own, from user interfaces to business workflows. Think of it as a no-code development based on radically new principles.
Long story short, I agreed to fix James’ predicament. It was a relatively easy task. With my tools, I had his entire system fully operational in production in just a few days. It was a simple gig, but it made me realize how much common good I can do by sharing my tools with others rather than keeping them to myself.
The statistics of software development are horrifying. Tiny projects succeed 61% of the time, medium-size ones get an 18% chance, and the success rate of large enterprise solutions is a mere 6%. Here, success means that the end customer is using the resulting solution in production, the project time is within 10% of the target, and the project cost is within 10% of the target (more details are in the Standish Group CHAOS Report).
Try answering a rhetorical question: would you ever hire a builder for your dream home when the chance of succeeding is 6%? Yet, we do it all the time when we build software. Gartner’s research shows that U.S. businesses in 2020 lost $2.1 trillion due to poor software quality, while technical debt reached $1.3 trillion (technical debt refers to the amount of money companies would have to spend if they ever decide to address all known bugs and deficiencies in their code). These staggering numbers mean far more than faceless economic losses. Behind them are shattered dreams, financial hardship, tremendous stress, and countless lost jobs.
This is why I created RISHON, to revolutionize software development. It layers a symbolic AI over the previously described approach. The AI’s role involves comprehending the specifications (the “WHAT”), resolving any missing or conflicting information (doing the job of a skilled solution architect), and determining all the operational aspects (the “HOW”). The specification changes as the business grows and evolves, and the AI adapts accordingly.
I fully expect RISHON to revolutionize the way early-stage startups operate. No longer will proof of concept be discarded, and the development of a minimum viable product will no longer come with a hefty price tag. Scaling and changing software will become a seamless and cost-effective process, allowing companies to achieve product-market fit much faster and with less risk. Startups will no longer waste investment money on technology that requires a complete overhaul in just a few years. Angel and institutional investors would enjoy reduced risks and more efficient use of funds by their portfolio companies.
Currently, nine out of ten startups fail. I fully expect RISHON to change this statistic, and pave the way for many great ideas previously held back by financial and technological constraints to see the light of day.
By the way, we are actively seeking design partners who create new solutions for their clients from a clean sheet, and those developing SaaS offerings. Together, we can improve RISHON’s capabilities while boosting your profit margins tenfold. If interested, please apply for early access (click on Early Access in the site's menu). For investor relations, email us at ir@rishon.com.
As always, I’d appreciate hearing your thoughts. Please feel free to connect with me on LinkedIn.
Many thanks for taking the time!
Anatoly Volkhover
Founder & CEO | RISHON AI
Founder & CEO | RISHON AI
