Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now? It seems like a pipe dream. It's built on some innate belief that someone can create tools that work for every kind of business possible, which is crazy. I can think in the past few years I've worked on health care registration websites, diamond auction websites, oil reserve management software - nothing would have been tied together with any common tool and all required extensive amounts of custom code for their business logic. I think it's time we drop this dream of normal "business analysts" writing all the software in a company.
> It seems like a pipe dream. It's built on some innate belief that someone can create tools that work for every kind of business possible, which is crazy.
It doesn't need to work for all every kind of business.
Often it starts with an excel sheet. Which works for surprisingly long, but eventually problems with concurrent data entry, or more logic / validation etc. really make that untenable.
But, going from a highly customized excel sheet to an in-house developed custom application is a huge leap; only when you start to replace it do you realize just how many Excel features you were actually using.
When you start writing a custom application, you need to take of authentication, permissions, audit logging, search functionality and so. Maybe your web framework helps you with some of them, but never all of them, and the missing concerns are a huge pain to get right.
I really want something, either a framework or a highly extensible application, to let me actually focus on the business logic. And at the same time, still let me deploy on premise, let me have a functioning CI/CD pipeline and keep my code in git.
For a complex project, it will be a programmer writing the code, not a business analyst. But they should focus 90% on intrinsic complexity, not on accidental complexity. We're not there yet, so we need something better.
> For a complex project, it will be a programmer writing the code, not a business analyst. But they should focus 90% on intrinsic complexity, not on accidental complexity. We're not there yet, so we need something better.
What follows is a tired argument, but hear me out as I'm using it as a springboard. The reason you hire engineers to design bridges is because they know how to do the important engineering bits. If all it took to make a bridge was knowing how cars will move from one side to the other, then we wouldn't need engineers. So...
We often want our software engineers to do all the business logic too, which is why engineers that provide the most value to projects are actually people who love building business solutions and not engineering software, or some blend in between. But maybe that's also why most software sucks and costs a fortune (sorry everyone).
Is the issue that we're conflating the two tasks into one? If so, is a product that would solve your problem one that cleanly delineates between software engineering tasks and logic tasks? Or is it one that gets rid of software engineering all together, if that were possible?
> I really want something, either a framework or a highly extensible application, to let me actually focus on the business logic.
I would argue there's already many relevant application frameworks that are good at this once you learn them, the trouble is the industry moves so fast between tools so your business solution specialist programmers spend all their time learning new software engineering paradigms.
> Is the issue that we're conflating the two tasks into one? If so, is a product that would solve your problem one that cleanly delineates between software engineering tasks and logic tasks?
Oh yes!
> Or is it one that gets rid of software engineering all together, if that were possible?
I have no problem with doing software engineering when I don't have the feeling that the problem has been solved dozens of times before.
Let me try to give an example: you run a colocation business. So you have to manage data centers, cages, racks, and the hardware that's in the racks.
I want a solution where the boring CRUD is mostly taken care of, so you get a list view of the hardware, you can filter it, modify and so on. You can also define some constraints (like, a hardware inherits the location from its rack) that are automatically enforced. And of course permissions are enforced, a customer can only see their own hardware, and can only access racks that contain only his hardware etc.
But I also want the flexibility that adds a rack view, where I can show a 2d graphics of the rack and where each piece of hardware is, which port is connected by cables to which other port etc. This is something that nearly no other business needs, so I'm totally fine writing my own thing for this view.
Software like ServiceNow allows the first part pretty easily, but it's expensive, cloud only (unless you pay several millions a month, I've heard) and doesn't have the kind of flexibility to allow me to implement the rack view, for example.
> Is the issue that we're conflating the two tasks into one?
I'd say it's the opposite. Business logic is software. More than that, bureaucracy is software too. Same goes for contracts, and laws too[0]. It's because "If <this> then <that> happens" is code. "Do <this bunch of stuff> until <this happens>, except when <something else happens>, do <that> instead" is code.
So when you're encoding the business logic in your software, what you're doing is copying some external code into your program, and translating it from natural/legalese to your programming language. With all the consequences this entails - you now have two independent pieces of code that do the same, are not visibly connected, and evolve separately. Whenever something changes in the way business works, someone needs to update that same code across applications that use it. Mistakes are bound to happen.
A big problem in the above is the state of the code you're translating from - the actual logic of the business. It's a continuously evolving system that's being developed by people who are specialists in business, not in logic. That's why business rules often seem sort of but not quite coherent, with exceptions and repetitions, and special cases. It's because people responsible patch them up as they discover problems, but the concept of refactoring or unit testing or integration testing of actual business rules is something between not known and not doable in practice.
So in the end, I'd think that yes, there's more than one type of jobs in here, but they're actually all software development. Not in the sense that they're all writing programs for computers - some of it is writing programs for humans (the bureaucracy) - but all of it could use some of the insights and tooling from software development. There is no separation between "software" and "logic" - there's only separation between what can be fully specified, and thus treated as code, and what cannot be specified, because it's too much tied to fuzzy, case-by-case value judgements.
(Going back to your bridge example: you hire civil engineers to design the bridge, but then again, you don't just go out and say "hey, I have money, go build me a bridge!". A bridge has to serve a purpose and integrate into other systems, which is why those bridge designers get input from traffic engineers, urban planners, and other engineers/engineer-likes.)
--
[0] - Now, to be very clear, I'm not on-board with the current ideas of "code as law", and I don't want them becoming reality any time soon. Fully specifying laws would require us to have total understanding of human values, which we don't have - that's why the role of human judgement is important, and that's the good reason for which laws are underspecified. Same goes for contracts and some business rules too.
[1] - They sometimes also have an incentive to keep things opaque. Sometimes a reason for a business rule to be unnecessarily lax may be that the "wrong" state is actually a "good" state to someone who doesn't want to admit to it. Think e.g. costs savings by trading off security or reliability, or tax evasion.
> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
Excel is that way now. It's programming for people who do not program, and it's no less mentally involved. It's just harder to extend beyond a certain point, because Excel is a pretty lousy development environment, and it typically doesn't have productivity helpers like source control.
It's also hard to port an Excel program to anything else because spreadsheets are their own programming paradigm, almost, although 'dataflow' isn't a completely alien term in the CS world.
> because spreadsheets are their own programming paradigm
They're reactive programming. Yes, the current hot buzzword. The stuff you do (or at least you're supposed to) when building React apps, or working with FRP libraries in your programming language. The stuff that boils down to defining a dependency DAG, and having the framework keep recomputing it as you change individual nodes.
Excel is that. There's actually a set of buttons in the ribbon somewhere, called "Trace Precedents" and "Trace Dependents" - when you click them, Excel will start drawing arrows between cells, showing you the underlying DAG.
(I literally used this yesterday to help someone I'm tutoring to understand how to rewrite the spreadsheet we've made in C++, and why these are two forms of the same program.)
Those exist; the one I'm most familiar with is Odoo. You download it, point it at a Postgres server and start it up. It shows you a web UI which asks you for a name for a new DB and a admin password.
After that, you get a login screen of a typical web app, but almost empty, with just a menu to configure users, groups and basic company info.
From there, you can create a module (just a folder with some basic metadata) and in it write a Python class with a few fields (like a Django model), and a menu linked to it. The system takes care of generating some views for CRUD: you just click the menu and it shows you a list of records, then click on a record to see an editable form, etc.
Permissions is just a matter of configuring in the UI or writing a CSV file that says which user groups can read and/or write which class / model, or you can write more complex rules (like users of certain groups can only see records created by them, other groups can see all).
(Disclaimer: I worked for a few years for companies that developed Odoo modules, but have left the platform for a couple of years now)
But a lot of things that used to require custom software ... don't, anymore. I think what happens is that the kinds of jobs that are stitched together with Iftt/Zapier/Google sheets/whatever stop being classified as "software," so we've got an ever-moving-target.
There'll always be a frontier that requires deeper technical expertise. But that frontier will keep moving.
I view my career through this lens now: I aim to find things to work on that I believe are very likely to remain in that frontier that remains classified as "software".
I find this useful when thinking about companies and projects. If they seem to be building a CRUD app with clients for different platforms, at a small to medium scale, that might not be far enough into the frontier for me.
This is purely a matter of taste or personality. Another very useful (and probably more lucrative) thing to do is to find ways to leverage the ever-increasing ability to build that kind of simple but useful application for some domain without writing much or any of your own "software". But for me, that just doesn't match my interests as well.
I think is better to say "software usable in 10 minutes" for people that is not a full time developer.
Things like excel, access fit there. The big mistake is not provide a way out the "click and get a full app!" step. This in when things go to fail with this kind of ideas.
---
I learn foxpro as my first language and is surprising how many "non developers" use it in the day.
I think it get loved precisely because was a bit "harder" than access: You hit a wall with access/excel much faster than foxpro/jupyter, making them for some people HARDER tools than the "harder" tool.
Not fun when things are easy, and suddenly, impossible. I say that we can give people credit and them could learn some complex stuff, as long fit well their use case.
I think the same. My side project is to build something alike. Programming move out "RAD" tools when the web come and making rad for web is near impossible, so somehow that translate "and then stop for everything else".
Ironic, because now with mobile it have a good chance!
It’s funny: nobody asks for “cars that don’t require technical skill to build” or “airplanes that don’t require technical skill to build.” Why this need to open up software development to people without development skill? As you point out, people have been banging this drum for decades! Why is it ok for some goods to require specialized skill to build, but for other goods the need for this skill is always seen as a problem that urgently needs solving?
People want cheaper engineering services, in all fields. some work and some companies are working on that. See "generative design" in Mechanical Engineering and Architecture.
As for the demand for software tools ? Old startups in that field are starting to show good results, there's money available, so it looks like a good opportunity for a VC.
I don't know if "software that doesn't require any tech skills to build" is realistic.
But a lot can be done, much faster, with much less expertise required, using modern "low code" tools.
Just a few examples from the OutSystems marketing materials(i can't vouch for them, but still):
------------------------------------
"Eighteen applications are already in productive use, some of which have hundreds of users.
The company has succeeded in its aim to make research scientists self-sufficient, so that they can build and deploy mobile apps for high-speed experiments, without clogging-up the central IT development team."
> Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now? It seems like a pipe dream
Whether or not it is possible, it means nothing that it hasn't happened in 25 years.
25 years may feel like a long period of time, but it isn't when we're considering the development of technology. In historical terms, we're still in the infancy of computer technology.
> Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now?
Does anyone here have examples of startups/products that tried to build "no-code" tools historically and failed? (aka. more examples like "Dreamweaver"?)
I don't have too much historical context on this stuff and would like to look at the graveyard. :)
Programming shouldn't exist. Problem solving, algorithm development and logic decomposition/recombination should exist instead.
To me, and I presume to the author, "no code" doesn't mean no engineering but the exact opposite: do away with mechanic vocabulary to vocabulary translation work and focus on the actual skills, which are decomposing requirements into atomic units of work and (re-)combining them in a manner making the domain understandable if expressed as code.
> focus on the actual skills, which are decomposing requirements into atomic units of work and (re-)combining them in a manner making the domain understandable if expressed as code.
That's literally almost all there is to programming; the rest is just typing things up.
What we program in now is a thin veneer over machine code. And as you point out, it's been 50 years. We're supposed to go totally code-free in the next 10?
