It’s much easier for most people to write an English statement than it is to use symbols. So I decided data processors ought to be able to write their programs in English.
— Grace Hopper
Commodore Grace M. Hopper, U.S. Navy. Photo by James S. Davis, public domain.
My grandfather was a ship builder who built many of his own tools. Not because he could not buy them, but because the tool he needed did not exist in the shape the work required. I think we are returning to that. In the future everyone will be building tools to help them do their job.
We now live in an age where anyone can build software, and I believe this leads to a golden age of organic software, built by domain experts to be of the domain, not thrust poorly into a domain to make money.
In The Split I argued we need a layered system, and that the first layer, domain oriented builders, the teachers and farmers and nonprofit directors who are domain experts first and not software engineers, need training that is not a CS degree. I did not say what that training actually is. This is my attempt.
Organic Software
I am borrowing the word organic from Frank Lloyd Wright. He wrote that a house should never be on a hill, it should be of the hill, belonging to it. You do not level the ground to make room for the design, you let the site shape what gets built.
Most software is on the hill. It arrives from outside the domain and the domain reshapes itself to accommodate it. Anyone who has watched a hospital reorganize around an EHR, or a nonprofit rewrite how it describes the people it serves so the CRM will accept them, has seen this. The tool wins and the practice bends.
Organic software is the other direction. It should not sit upon a domain, it should increase the capability of the domain, extending what the practice already does well through tooling fit to the environment. The test is simple. After the tool arrives, is the practitioner better at the work they already knew how to do, or are they doing a different job made of workarounds.
Earlier in my career I intentionally took a job at a small bike company, wanting to grow by taking on as much of the software design and development work as I could myself. I did grow as an engineer, but the bigger lesson was how much better software gets when it is designed to purpose instead of configured to fit.
That was clearest in a warranty system I built. It understood the entire setup of a bike and the supply chain behind it. The previous system could tell us a part was failing. It could not tell us why. You could not configure it to hold the correlation between a design choice, a supplier, and a warranty issue at the same time, and each of those has an impact. Multiple causes can be the source. Is this a supply chain issue or a design issue. A general purpose tool cannot get you there, not because it is badly built, but because correlation in manufacturing is multifaceted and that is very difficult to model in a system not designed for deep customization. Modeling it was the hard part, and I did not fully appreciate that at the time. It is why modeling comes first in the list below.
Why it is possible now
The economics that produced generic software are collapsing. Building software was expensive, so it had to be sold into many domains to pay for itself, so it had to be general, so every domain ended up with something shaped for nobody in particular. That was not a failure of care, it was arithmetic.
A friend of mine consults with startups. He recently met with a small company building software for rabbit farming. Real market, real customers, and their technical needs are not particularly difficult. What is stopping them is the cost of software engineers, building and maintaining the product costs more than a market that size can support. Rabbit farmers are gatekept out of good software by an economic accident, not by anything about rabbits. I suspect there are thousands of markets like this, small and specific and perfectly real, that never got software because the math never worked.
As the open source movement taught us, those who care deeply about a problem produce the best software to reduce it. The Cathedral and the Bazaar opens with the claim that every good work of software starts by scratching a developer’s personal itch, and spends the rest of the book showing why the Cathedral, the large tech company, cannot scratch an itch it does not have. The limitation up to now has been the extreme skill required to build. Abstraction layers pushed the complexity down, and SaaS companies such as Shopify and WordPress greatly reduced what was needed to build some types of software, largely in very profitable areas where the incentives existed.
Every one of those abstraction layers let a new group of people in. Compilers, then the web, then SaaS. And each step was resisted by the people who had mastered the layer below. Grace Hopper had a working compiler that nobody would touch, and was told flatly that computers could only do arithmetic. What strikes me is that widening the door was the entire point for her. She was not trying to make life easier for mathematicians. She thought data processors ought to be able to write their programs in English, because most people are not symbol manipulators and never will be.
AI is the next layer and it is a big one. We can build more software now than we ever have, and far more people can build it. The rabbit farmers can have their software. The question is no longer whether people are allowed to build, it is whether we prepare them to build well.
So what does this group of makers need to be successful? I think it is split into a few pieces, building tools, platforms and knowledge. The knowledge is directly related to the platforms and tools, so it will change as they evolve, as does all necessary knowledge to perform a task in a field. Which raises the question, what translates across many platforms and tools, the principles of the field.
I will propose what I think is necessary based on a number of conversations I have had with folks and my own opinions. These build on each other, roughly in the order below. What am I modeling, what constraints am I under, what do I build with, how do I know it worked, and when is it no longer mine to carry. That is the order they depend on each other, not the order I would teach them. In a project the concepts get named as the builder runs into them.
Domain Data Modeling
All software systems are an attempt to model state in a domain into data types, then to operate on that data to create change. Translating a domain into data has many intricacies that are difficult to map out and it can range across many parts of the system. How is data stored in the database, how is the website organized, how might an AI find data in a system based on user input.
I believe this field will grow silently and immensely. Today much work is done to translate a domain into an existing tool, which may be very inflexible, often leading to the difficult work of manipulating the domain into the tool. This is one of the biggest changes coming in computing systems. It will be much easier to build a tool precisely fitted to a domain, making a better tool, as all computing occurs on data.
System Qualities
Often referred to as architectural qualities, or quality attributes. Understanding the constraints a system is operating under is vital to properly fitting software into a domain. For example is the data highly sensitive, this means you have a need for tight security. Discovering system qualities takes work and helps inform the building materials and the design in general. I do not think domain oriented builders will be greatly involved in ensuring these qualities, they will instead have platforms that may not yet exist that they choose from to satisfy them, which brings me to building materials.
Building Materials
Choosing building materials is an important step in any building process. It is possible to just go to AI and say choose building materials for my site, but success depends on picking the correct ones. System qualities are the guiding light for constraint satisfaction, though not in isolation. I could store all my data in files vs a database for example, and knowing when one is appropriate and the other is not, and having the language to understand what the options even are, is key to successful choice.
Determinism vs Non-Determinism
I consider this an extension of building materials, but I am calling it out because it is new and generally not understood or well taught. AI and deterministic programs each have their place, and understanding which to choose when and how to combine them is a helpful set of knowledge to have. AI is very good at creating deterministic scripts, using such scripts, and setting them up for humans to use absent AI. Moving fluently between these modes is a new skill worth mastering, and it is very insightful to learn from a philosophical perspective.
Basics of Computing
Tied up in determinism, non-determinism and building materials is the core grounding in how computers compute. How does AI actually use stats to make recommendations, how do deterministic programs work, how is data stored. At this level a deep understanding is not needed as much as an appreciation for the building materials, such as a carpenter has an understanding of types of wood, but not how a tree grows per se.
Usability and Domain Fit
This is a big one. To produce truly organic software a domain expert must not only have a deep understanding of the domain, they must be capable of evolving their creations to better fit it as other perspectives become available. That requires attention to critique, skills around evaluation, prototyping and some design sensibility.
Knowing It Works
In The Split I pointed at some uncomfortable numbers. 87% of AI generated pull requests contained at least one security vulnerability. AI co-authored code contained 1.7x more issues than human written code. I do not think the answer is teaching domain experts to read code. I think it is building tooling to support them in the parts they cannot verify.
Knowing it works for a domain oriented builder should not rely on understanding deeply whether the system is secure, whether it scales, or whether it is a complete mess. If these builders are worried about that we are missing an important abstraction layer they require to be successful, and the software engineering and computer science levels of the system have not properly done their job.
But one part does not abstract away. A platform can guarantee the thing is secure and that it scales. A platform cannot tell a teacher whether the summaries are any good. Knowing what good looks like in the domain is the whole reason she is the one building it, and that judgement has to be made systematic. Write down what good looks like before you build, check against it after, and check again when the model changes underneath you. Non-deterministic systems do not stay correct on their own. Something that worked last month can quietly stop working and nothing will tell you.
That is a different kind of evaluation than software engineering has typically done. It is closer to asking whether a tool fits its environment than to asking whether a program runs, and it is a strong reason I feel this migration will be beneficial to society if done properly.
Knowing When It Is Not Yours Anymore
In The Split I described a teacher whose small reading tool gets popular, then the principal wants it, then the district. Success changes the risk profile, and responsibility has to move as consequence moves.
That handoff only happens if the builder notices, so noticing is part of the curriculum. When did I start holding other people’s data. When did someone start depending on this to do their job. When would an outage hurt somebody. These are not technical questions and they do not require technical training to answer. They require someone to have thought about risk before it arrives, and to have decided ahead of time where the lines are.
I do not want people afraid of their own tools. I want them to know when the work outgrew them, and that handing it off or asking for help is a success and not a failure.
What the Tool Does to People
In We Build The Tools That Shape Society I argued that engineers built the anxiety machine because we were measuring the wrong things. We watched uptime and engagement and shipped features, and the harm was visible in our own research the whole time.
Domain experts are not automatically immune to this. Good intentions are not a metric. A tool can work exactly as designed and still be doing damage, so part of what we hand these builders is the habit of asking what it is doing to the people using it. A teacher building a reading tool should be asking whether her students are reading more or reading less, whether they are thinking or outsourcing the thinking.
Domain experts do have an advantage. They are close to the people they are building for, often in the same room. The feedback loop that Facebook had to buy through research studies is just their Tuesday. But proximity only helps if you use it on purpose.
How do we teach this
I will not claim to be an expert teacher, I have taught as a novice and have opinions, and I have spoken with a number of experts. Generally I am of the opinion that project based learning is key. When AI can quickly spit out applications that satisfy much of what is needed at this level, growth can not be measured in terms of can you pass this test. It has to be measured in the ability to produce a product that is truly organic in the environment.
Take the teacher and her reading tool. The assignment is not build a reading tool. It is find a problem in your own classroom and build something that solves it well enough that you keep using it after the course ends. That last part is the real assessment. Software that gets used is software that fit the domain.
If I had to write the rubric it would be something like this. Did you model the domain in a way that survived contact with the real thing, or did you keep bending the domain to fit your data structure. Did you choose your materials on purpose, and can you say why. Did you find out you were wrong about something, and did you change the tool in response. None of these are can you build it. AI can build it. The question is whether what got built belongs in the environment.
The hardest part is critique, although it is well solved in other domains. Art and architecture have been refining the studio crit for a century. The work goes up where everyone can see it, the maker presents the intent and then listens, and the response is structured so it lands on the work rather than the person. Most people building something they need are building for themselves, and the leap to building for others requires putting your work in front of people who will tell you it is wrong. That is a practiced skill, not a natural one, and it has to be structured into any program that tries to teach this. We do not need to invent the format, we need to borrow it.
A future to look forward to
As we develop a large cohort of makers well versed in the domains they are affecting, we will need new tools to help them build in increasingly regulated industries. That is a whole new category of platform, and a whole new category of problems getting solved.
But none of it happens without the training, and right now nobody owns the training. CS departments will not build this, it is not their discipline and I do not think it should be. Bootcamps were built to produce junior engineers for a job market that is changing underneath them. The platforms have every incentive to teach their own product and not the principles underneath it.
So it is an open question, and I think it might be the most important one in this series. We have spent a lot of energy arguing about whether domain experts should be building software. They already are. The question is who is going to teach them, and what.
This post is a continuation of The Split and We Build The Tools That Shape Society.