An anti-example is admin dashboard generation, with ability to customize some parts that requires customization.
Admin dashboard is an interesting problem. To me, to build an MVP means to quickly scaffold an Admin dashboard. Then you can iterate the domain model until it fits the requirements.
Sadly, not enough open source project which is successful to quickly craft a customizable admin dashboard.
Note: Codeless in this case means you configure the dashboard through a json file instead of canvas.
I work with Salesforce that actively pushes 'point and click' configuration to the naive CEOs while at the same time making billions from ever increasing development required to make all the stuff work. Codeless is fine for some genuine vanilla cases but anything beyond that requires code and will continue to do so in the foreseeable future.The only real thing that is changing software field is ever growing abstraction,which does simplify a lot of things.For instance, to create a simple CRUD web app nowadays is a relatively simple task compared to what it used to be 20 years ago. However,even with all the abstraction,the simplicity ends up when complex business problems show up.
>Suddenly you find yourself looking for programmers who are well versed in the specific low-code platform that you bought, and it is a really hard task.
Yes, customisation of "codeless" platforms is typically narrow. You can easily customise the parts the developer anticipated that users would want to customise. When you need something else, customisation is limited and painful.
Ugh just like seeing my current CEO. Guy is "configuration over development", but he will not see point where that configuration will become development. It will in year or two get so complicated that you will not be able to get any guy from the street. But extensive training for 6 months will be needed, just like hiring developer.
To get Salesforce you already need trained consultant to who you pay $$$ and yeah those CEOs don't see it. It is just, developers do some magic and are expensive. Where I don't understand what Salesforce consultant would do and he would also be expensive.
A lot of "software" that is currently being developed are relatively simple CRUD applications. A developer shouldn't be required to create these kind of applications. (Most developers also don't enjoy creating these kind of applications, so that is a good match...)
For this category of software, there are increasingly better and modern platforms and frameworks without the need of writing any code such as Microsoft PowerApps, Mendix and SalesForce. That also explains the lately success of these companies.
I think it's worth reading the sucsess stories of mendix/outsystems about using their low-code tool to build complex software , like hospital management systems or hospital analytics system, and than try to form an opinion.
> Every couple of years, the hope surfaces that a simple graphical interface will replace teams of developers. Business people to quickly and easily create beautiful expressions of their ideas and launch them into production seamlessly. A handful of startups in every generation take up this challenge, and they mostly fail.
Thanks for this great example. I love MaxMSP and I participate in NYU ITP Camp every year where I am amazed at how many creative problems I can solve using MaxMSP. You are right about these solutions not scaling as enterprise applications, but they are valuable within the right context and the ability to share sketches is also great for learning to go deeper.
If you don't mind sharing, what's the company that uses MaxMSP in their workflow? I love finding these creative examples and am curious for added context.
Unity3D game engine is a proof by counterexample that you can be lowcode for creatives and analysts while allowing engineers to fluidly drop down levels of abstraction and control the code, without big rewrites.
I definitely agree with you there, though for moddable games... my experience has been the opposite of low code.
Modding feels like fixing a plane in flight, except someone else built it, it has two nosecones and three wings, and there are twenty other mechanics, some of whom are running around adjusting the things you just tuned up, some of whom aren't actually mechanics, they just like wrenches.
It feels closer to programming anarchy than any open source project I've participated in, and it requires being very comfortable with writing nothing but hacks. Honestly I think it requires a level of cleverness that you should not need in a programming day job, because only masses of technical debt that have gone critical need that much cleverness.
For context, my modding experience comes from Stardew Valley, Rimworld, XCOM 2, and BattleTech.
This is the key to it, what is low-code good at and staying within that box while giving the ability to easily get outside that box when needed. With these successful examples, I have seen horrible abominations that should have never been made and are impossible to support because we "had" to take that low-code tool one more step beyond it's capability.
The article doesn't get to the reason that it's doomed to fail. Software developers translate between what humans want and what computers can do. The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially. The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface. Tasks involving concepts in the domain of human desires can, too, be automated, but the technology needed to do so would be AI-complete. In other words, if we had a technology that could automate the work of software developers, the same technology, with relatively minor changes, could be applied to automate any human occupation, including those of the people who want to automate software development.
Until then, what we can do is build abstraction on top of abstraction over what computers can do. But that is code. There's a lot of room to make application development easier, to make it require less knowledge. In a lot of cases there's no good reason it isn't easier already. But it can't really become easy until the target stops moving; what computers can do changes too fast for people who want to build a good unified set of abstractions over it.
> The first part, what humans want, is a profoundly complex anti-inductive domain that every human in history has spent their whole lives trying to understand, failing to but scratch the surface.
Yes, this! It's the inquiry into the way the data flows, what the application should do, and how to handle edge cases that is difficult for a lot of business applications. To say nothing of getting various stakeholders to agree. Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table (others can too, but I've seen it far more often with developers).
That's not to say that there aren't more and more domains that will be codeless. As another commenter says, if you can stay in a box, a codeless solution like Wix or wordpress.com can solve your problems quite well. But as soon as you step out...
Another issue that is never brought up is lifecycle and change management. This is a complex topic that developers spend a lot of time thinking about. Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.
> Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.
Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales?
As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.
When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs.
What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper.
Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product.
Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.
Thank you, that helped me understand the point much more clearly. It sounds like a cogent example of 'technical debt'; I'm aware of several software products that have tried to expand their capabilities by purchasing others' source code and have eventually run into similar roadblocks.
That's a very waterfall way of looking at it. "Business have requirements, we have software, if we just understand the requirements we can build the perfect system". I could hardly disagree less.
Software is deliberate, yes. You need to know what you want to do at a pretty detailed level, but that's not the challenge. The challenge is that this new technology (what software can do) is a gamechanger for most traditional businesses. It creates a lot of new opportunities by enabling ventures you couldn't even imagine before, and every time you build more, you get more opportunities. Software requires you to reevaluate what you were doing previously. That's hard.
Software is also fluid. As you get more software, you see more opportunities. As you get more, you want more. Anything that tries to treat the domain as "static and understandable" is doomed to fail. Development is not the steady march towards the perfect system. Development is the discovery of what you can do with software, and how that changes the business processes that already exist.
>what computers can do changes too fast for people who want to build a good unified set of abstractions over it.
I was with you until this line. Is it really the case? x86 has been with us for... a while, and x64 is backwards compatible. We built an abstraction on top of that, a compiler that can take high level languages and turn it into machine instructions.
I think what people are looking for next is a compiler that can take something even higher level and "compile" it into high level language. The issue is that if you get too abstract, a standard compiler stops being able to make good guesses about your intent. However, if you built a "high level compiler" around specialized domain-specific use cases, then you might be able to make reasonable higher-level guesses about intent (though as with normal compilers, you'd need support for advanced developers to work around those assumptions).
I was also hesitating over that line. Maybe it's implied that computers enter new business areas all the time, which certainly is true. I have been in the game long enough to notice the same patterns of explosive growth and associated API chaos etc etc. Nowadays you can do everything in Node.Js for instance, but first you had to "reimplement all things!" except in many cases they didn't know (or care) they were reimplementing.
I usually snark on Node.js but not really in this case, I understand well when the platform imposes a moat and it's easier to just re-do than integrate. Ain't nobody got time for that... it's still something of a tragedy but it's not something we have an easy fix for.
Not only advances in hardware affect what computers can do. Advances in software let computers do more things, but we can't count those when considering automating all software development, it wouldn't make sense. But there are advances in the capabilities of computers that are neither hardware developments nor the job of software developers, namely business/legal and theoretical advancements.
So some new "things computers can do" from the last 20 years:
- Fit in our pockets
- Communicate wirelessly between any two major population centers on the planet, with high bandwidth
- Store exabytes of data
- Do excellent pattern-matching of all sorts of data
- Be close to your customers, wherever they are on the planet, without you needing to have a ton of capital upfront
- Cost as little as $7 while still being compatible with our complex software stacks
- Be powerful enough to run an Electron application
- Monitor your blood glucose levels and deliver the right amount of insulin in real time
I think you nailed it with the reference to a higher-than-high-level language being the next step. We went from binary programming (punch cards) to machine code to assembly to early low-level languages to high-level languages and then just kind of stopped there at the abstraction level. But do we really need to be manually coding in if statements, loops, data storage schemas, etc. over and over again when end users really don't care about any of those things? I hope eventually we'll get to a "super-level" language future where developers still input highly specific and organized needs, but not at the level we see today.
The real world has a whole lot of "ifs" in it. "If it's this hardware rev, do this." "If the employee is a manager with more than five reports, they need to take this training." "If the account is more than 30 days delinquent, then send a second notice. If it's more than 60 days delinquent, call. If it's more than 90 days, begin collections."
Because the real world is like that, there is no possible programming language that is going to prevent the need for "if". Users may think they don't care about that, but the requirements are full of "if".
Loops you don't need to code today - if you don't need too precise a control over execution. If you need real control, you probably need to write the loop instead of just using a comprehension.
Data storage schemas: As databases scale, efficiency of storage start to add up to real money. The user may not care, but the finance people care a great deal.
> do we really need to be manually coding in if statements, loops, data storage schemas
No, not necessarily, depending on the business requirements. There's already logic programming, for example a language like Prolog. You the programmer input a very high-level description of the rules that your information must follow. The computer figures out all the imperative bits.
Maybe declerative programming could help with that, like prolog/datalog. I don't think you can go much higher than inputting only the rules and data of your app, the only thing more higher than that I could imagine is an AI that could create a program written in a declerative language with only a subset of the rules, figuring out the rest by itself - which is pretty much what developers do
There's also block programming. Eg. You put puzzle pieces together. But mainstream languages are becoming really abstract. See for example Rust and JavaScript et.al with async/await, generators, coroutines, etc.
> The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially
I have a chipset that I'd like modeled, and can I have some trivial drivers by next Tuesday?
Modern computers are not trivial. They are probably the most complicated devices on the planet, full of features, edge conditions and screw cases that are not obvious even to very skilled developers. I've done some very fast platform bring-ups and gotten them to ship, projects organized to be very light-weight and agile (in the non-political sense) and it's still many person-years of effort and a bunch of time on the phone with vendor support, discussing chip-level bugs (can that model please include the bugs? That would help a lot!) No talk at all about pleasant abstractions, we need to ship this pile of silicon.
Visual interfaces are for toy programs that spend resources on making pretty illusions of how the world should work. Underneath the pretty glitz are piles of slain dragons and machinery that people take for granted and apparently think can be wished away. That's fine for end-users and application level folks, assuming they can get their jobs done without resorting to breaking the abstractions (and any sufficiently large or long-lived project will). But someone has to worry about memory management, concurrency and synchronization, all the drivers for fucked-up hardware that (say) locks up when you fire data at it too fast, what happens when the file system fills up or that configuration file is mangled by an upgrade. All that nasty stuff that the "drag a blue wire from point A to point B -- see, easy!" doesn't handle, and never will.
On one project we had a clock that would, very occasionally, go backwards in time. It took a calendar year of going back-and-forth with support and ultimately a phone call with the chip architect to figure out the problem (the workaround for the bug was unpleasantly expensive). It's easy to model a clock and come up with a set of expectations. It is much, much harder to make a clock work in the real world. You would not believe how hardfought some of this stuff is, for features that are "trivial".
Visual programming is great when it works -- I've certainly done my share of it -- but we should not mistake ease-of-use in some domains for revolutionizing programming in general, or (worse) expecting the paradigm to work when things get complicated and large.
Note that the "trivial", as used in this context, probably means something more like "we know the domain pretty well", versus "can be completed in 5 days". There are still some ghosts, but I believe OPs point was that pales in comparison to the demons invoked when trying to "calcify the business process".
- dealing with the environment. My program always works perfectly until it moves away from my laptop.
- debugging. If you don't know how to code, good luck to find the error in your system.
- interfacing. Your codeless stuff is going to work fine for everything that it already know. But new stuff are coming. Somebody will need to code for that.
Now I do think that eventually AI will be able to manage all that. And that it will give human a fuzzy codeless experience. But it will take A LOT of time before we get there.
I disagree with codeless software being doomed to fail.
I’ve built lots of applications without code (and teach others how @ https://www.makerpad.co/) one being a mini Netflix ‘clone', Airbnb ‘clone’ and Fiverr ‘clone’.
They may not be able to withstand Netflix level of users and usage but why should every startup/business have to aim for that. It could service hundreds/thousands of users and turnover great revenue for those running it.
I think that's the point of the article - the moment you try to "tweak" a clone/"codeless"/"softwareless" tool with customizations, you end up writing code, hiring developers, and eventually scrapping and rewriting the said clone.
how many products with users have you built without code?
while very valuable for learning, i find that folks building thematic maker sites (no code, react/node, rails, etc.) are very biased towards their own way and often haven't made a "real" product built on what they profess.
engineers would be better off using "no code" more often, and non-engineers would be better off learning just enough react, python, etc. to ship something.
otherwise, everything begins to look like a hammer.
Ugh. I got on board in 1990, COBOL was still around and 4GLs too. Nowadays there are focused efforts to cater to 'citizen developers' with pared down scripts.
They all fail to live up to the hype. I think it's because you have to have a good general understanding of how things work to properly build (and initially test) software.
Reminds me of what people used to say about website builders such as dreamweaver, then about the "cloud", and more recently about "serverless".
Wix and squarespace are more than enough for many businesses' needs. AWS has blown through the roof. And more and more people discover what it feels like not to have to worry about hardware and VMs configuration.
ForestAdmin is also a nice case in point, supposing you have the proper stack.
Sure there will always some who need developers, and most "solutions" this far haven't been up to the task. But I definitely wouldn't bet that won't ever be more than enough for most people and use cases.
For this, extensibility (via integrations and proper established languages; definitely not some absurd and ill-conceived "very friendly script language") will be key
I don’t think the article is about “serverless” - it’s more about various BPM, RPA and similar tools and technologies that tend to popup with snake oil type marketing every a couple of years.
Also serverless is arguable more complex for a business person/analyst to grasp than just telling a developer to create something they imagined.
Yes, analogy is similar, the gap though is much larger (even though it’s barely noticeable).
I guess eventually a new gen of Excel comes out that can write code without IF, FOR loops, and function calls, but until then it’s safe to say anything writing those statements other than in code is pretty much snake oil.
The problem is that IF ELSE statement or even calling some functions is easy, however most people are shit scared of it.A person of very average intelligence can do it,but most people will never dare even to try,hence the popularity of all sorts of drag&drop. Another problem is that if one isn't a developer,it is close to impossible to estimate how difficult the task could be. For instance, querying 1000 records in the database is easy but doing the same for millions of records doesn't translate into "oh, let's just do it a few more times".
Serverless solutions still need someone to write the code to run on the serverless platform. Serverless doesn't mean literally no servers, it just means the servers are 100% managed by the provider. For example Lambda AWS still needs a developer to upload the code for the Lambda to run.
Yes. I know. This has been my job for the past months, and all my personal projects for the past 2 and a half years. Still, no sysadmin.
As for the rest. No-code / low-code solutions don't just pass nice drawings / uml diagram to a gremlins-powered CPU. They rely (and will rely) on code behind the scenes.
Declarative configuration can work great if you understand the domain really well, you cover it, and it doesn't change very much or very fast or in fundamental ways that upend the problem.
I worked in this domain for a couple of years at one of the most innovative players (www.triggre.com). These platforms fulfill a really important role - they allow a far larger class of people to automate their own day-to-day work.
They compete with Excel, MS Access and possibly WordPress. They're never going to replace actual software development because once the problem domain gets complex enough the person behind the wheel needs pretty much all of the skills of a good software engineer. They're also pretty much all closed platforms so only an idiot would use them to build a product. So they're stuck in the small-scale automation hook.
I should add that it's a really interesting domain to work in. There is just so much to achieve there and so many of the players are focusing on the wrong things that there are really big chances.
I still have regrets that I left because it was intellectually stimulating. It's just impossible* to work in a startup culture whilst being a GOOD parent to young children.
* When you can't stay late when needed and your colleagues are picking up the slack it feels like sh!t and makes you feel like a massive shit; especially when said colleagues are amazing about it.
Most machine-learning models and AI's are "codeless software" as well, in a very real sense (while the architectures/abstract models that specify their parameterizations and the format of their inputs and outputs may be a sort of code, the estimated/"learned" parameters themselves are not!) I generally assume that they too are doomed to fail, and for the very same reasons.
Is there actually a platform where I could read a flowchart or story-board version of a novel? I can think of quite a few novels where this would have made my reading experience much better.
Thanks, Twine looks cool. I've never heard of it before.
It is kind of what I was thinking about - being able to read a story (in this case a branching one) by going over the diagram. Actually, thinking of it, Detroit: Become Human had a similar nice display of narrative choices.
I think there is natural threshold of inherent complexity of any problem to solve. Codeless or low code software can only go so far but never be successful beyond this threshold. It is the same point where the abstractions of the codeless software become leaky [1]. And, because codeless or low code means heavy abstractions, user will encounter this problem quite early already with simple problems.
> The reality is that whenever you are building software with any level of custom functionality, as in it does not come in the box, you are going to need people who are comfortable writing code.
In other words, if you are making anything with real value that doesn't already exist, you are not going to be able to make it through some kind of WYSIWYG.
On the other hand, just like DSLs are sometimes appropriate, writing a _domain-specific_ WYSIWYG could be appropriate, especially if it's for internal use and not the product itself.
I developed a graphical drag and drop bioinformatics app for the biologists at the hospital I used to work at. I’m not sure if it was more efficient than a command line for a skilled practitioner, but it ended up working pretty well all things considered.
As long as what you’re doing is not Turing complete, I think WYSIWYG has value.
I am under the impression that low code platforms thrive because you need less skilled people to work with them, and still are able to build your app/whatever.
Yes it's still better to have skilled engineers, but they're expensive and hard to find nowadays, and not every company is even capable of hiring them effectively.
Block diagram based "codeless" software might not be a one-solution fits all, but it's certainly effective in a number of domains. I'm currently making the transition from writing physical simulation code in Fortran, Python, and C++ to Simulink with great effect. And "codeless" Labview has long dominated equipment controllers in laboratory settings.
I second the Simulink/MATLAB ecosystem. While it's ridiculously expensive, Simulink blocks can solve most problems and generate well-formed C code. But oh my god it's annoying to work in for me with a CS background amongst mechanical engineers.
I think the author is limiting his perspective to that of a software engineer.
No web developer is charmed by the limited capabilities of Wix, but it's good enough for the static website many (if not most) businesses are looking for. A CRUD app made by a low-code platform may be limited in its functionality, but it's often good enough for a typical business need. To say it's doomed to fail is an overstatement.
Services get more fine-grained every year, and composition of these services is where the money will be made in the future. AI might resolve some of the issues with finding the right services for the right use cases & even integrating them.
Custom, home-made services will be a conscious choice, and might be composed of other services that are publicly available or not. Everything else will use off-the-shelf services.
I dunno, I see the pendulum swinging back again. Or it might just be my contrariness. But building anything decent out of stitching together various third-party services with the baling twine and duct-tape of HTTP... it's not going to end well, and I think people are realising this.
I don't think we are too far off and AI will be the key. Sometimes I like to remember that anything a computer can do can be done by thousands of people in an office. Take a program you've worked on and think about how you would have implemented it with people instead of code, where each person is a function and the data gets passed on a piece of paper. The designed workflow would be easily described to people, and any exact processing would need to be demonstrated to the worker. The super fine details of processing are usually pretty easy to understand as well as the high level. It should just take some AI assisted translating to find the appropriate processing models for the high level requests, with the ability to learn by demonstration for the edge cases.
I mean, thousands of people are highly concurrent while computers are not, so I don’t think the analogy really holds. If you had people as “functions” and organized them like a computer program, only maybe one person out of a thousand would be doing anything at one time.
It is a mental exercise to re-frame the problem. Sure it would be inefficient but the point is every stage could be done with reinforcement learning from a high level abstract design without every dealing with 'code'.
I don't think you've solved the "low code" issue at all. You still have to define the process to the same level of detail; you're just thinking about it differently.
What your approach does do is create a system that is easy to parallelize. You want to run on thousands of cores/threads? Make each "person" a thread, and there you go.
The truth is, this space just gets better every year. You can get more and more done with less and less. Sure, you still can't build arbitrary programs without at the very least a general-purpose programming language, but if you can constrain the solution space just a little bit you'd be very surprised at just how far you can get without needing to break out a text editor.
I've seen the exact scenario mentioned in the article play out, "the moment you need to create something in a domain that does not fit existing tools, you are already into the domain where you will eventually need programming done, and in that domain, you need a programming language, not a drawing tool."
I worked somewhere with a team of engineers who worked in LabView. They used LabView mainly for customized test equipment controllers and recorders and it worked well. They then branched into FPGAs for some straightforward dataflow signal processing and that also worked well. They then decided they were sick of how long it took software engineers to write device drivers for custom hardware and decided to do that in LabView with some tool that could generate C code from LabView. I got pulled into a meeting about it. I asked a couple important questions: how do you insert memory barriers and how can you write code that is ISR safe? It was clear the LabView folks had no idea about any of this. So I launched into a discussion about CPU architecture. They didn't really listen and everything was a hand wave, "LabView does that for you". It was clear they didn't want to hear my thoughts, so I let it go.
Fast forward 6 months and I get a frantic call from a manager if I had "bandwidth" to write a device driver in C for the same card where the LabView team was supposed to have written the driver.
Similar experience with a Q/A team using LabView. They had a tool they were comfortable with, and had inevitably created a fragile, horrid monster that looked like a plate of spaghetti. Their test framework was probably nice and intuitive for six months before rot set in, and then no one could understand it.
A new project rolled in that didn't meet the expectations of their tooling, and suddenly they had to start writing native code plugins and so forth, and they were totally at sea. They started demanding engineering resources and invasive changes to the product so their test environment could handle the thing with minimal modifications.
I remember telling one particularly obstinate contractor that we were colossally uninterested in writing drivers for their environment, and that he was either going to learn C or lose his contract. I didn't see him again, maybe his management chain told him not to come 'round the software group again, or maybe he learned C and saved the day for his team.
149 comments
[ 5.4 ms ] story [ 83.5 ms ] threadAdmin dashboard is an interesting problem. To me, to build an MVP means to quickly scaffold an Admin dashboard. Then you can iterate the domain model until it fits the requirements.
Sadly, not enough open source project which is successful to quickly craft a customizable admin dashboard.
Note: Codeless in this case means you configure the dashboard through a json file instead of canvas.
>Suddenly you find yourself looking for programmers who are well versed in the specific low-code platform that you bought, and it is a really hard task.
To get Salesforce you already need trained consultant to who you pay $$$ and yeah those CEOs don't see it. It is just, developers do some magic and are expensive. Where I don't understand what Salesforce consultant would do and he would also be expensive.
For this category of software, there are increasingly better and modern platforms and frameworks without the need of writing any code such as Microsoft PowerApps, Mendix and SalesForce. That also explains the lately success of these companies.
I think it's worth reading the sucsess stories of mendix/outsystems about using their low-code tool to build complex software , like hospital management systems or hospital analytics system, and than try to form an opinion.
https://ryortho.com/breaking/kermit-using-mendix-helping-hos...
https://www.outsystems.com/blog/introducing-sapphire-hospita...
well, I used to work in a company where a lot of software were written in Max/MSP (https://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/fi...). Sure, it wasn't very maintainable, but it allowed one person to iterate very fast.
I've also used some CRUD apps which were entirely made in MS Access (D&D 3.5 eTools :) ).
<!-- <span class="meta">Posted by <a href="#">Start Bootstrap</a> on August 24, 2018</span> -->
Excel/sheets, wordpress, MS Access, moddable games, arguably even the web itself...
Modding feels like fixing a plane in flight, except someone else built it, it has two nosecones and three wings, and there are twenty other mechanics, some of whom are running around adjusting the things you just tuned up, some of whom aren't actually mechanics, they just like wrenches.
It feels closer to programming anarchy than any open source project I've participated in, and it requires being very comfortable with writing nothing but hacks. Honestly I think it requires a level of cleverness that you should not need in a programming day job, because only masses of technical debt that have gone critical need that much cleverness.
For context, my modding experience comes from Stardew Valley, Rimworld, XCOM 2, and BattleTech.
Until then, what we can do is build abstraction on top of abstraction over what computers can do. But that is code. There's a lot of room to make application development easier, to make it require less knowledge. In a lot of cases there's no good reason it isn't easier already. But it can't really become easy until the target stops moving; what computers can do changes too fast for people who want to build a good unified set of abstractions over it.
Yes, this! It's the inquiry into the way the data flows, what the application should do, and how to handle edge cases that is difficult for a lot of business applications. To say nothing of getting various stakeholders to agree. Code isn't fluid, it's calcified business process. That calcification requires regimented thought that developers can bring to the table (others can too, but I've seen it far more often with developers).
That's not to say that there aren't more and more domains that will be codeless. As another commenter says, if you can stay in a box, a codeless solution like Wix or wordpress.com can solve your problems quite well. But as soon as you step out...
Another issue that is never brought up is lifecycle and change management. This is a complex topic that developers spend a lot of time thinking about. Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do.
Well said.
I should revisit with more modern examples.
Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales?
As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.
What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper.
Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product.
Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.
Software is deliberate, yes. You need to know what you want to do at a pretty detailed level, but that's not the challenge. The challenge is that this new technology (what software can do) is a gamechanger for most traditional businesses. It creates a lot of new opportunities by enabling ventures you couldn't even imagine before, and every time you build more, you get more opportunities. Software requires you to reevaluate what you were doing previously. That's hard.
Software is also fluid. As you get more software, you see more opportunities. As you get more, you want more. Anything that tries to treat the domain as "static and understandable" is doomed to fail. Development is not the steady march towards the perfect system. Development is the discovery of what you can do with software, and how that changes the business processes that already exist.
I was with you until this line. Is it really the case? x86 has been with us for... a while, and x64 is backwards compatible. We built an abstraction on top of that, a compiler that can take high level languages and turn it into machine instructions.
I think what people are looking for next is a compiler that can take something even higher level and "compile" it into high level language. The issue is that if you get too abstract, a standard compiler stops being able to make good guesses about your intent. However, if you built a "high level compiler" around specialized domain-specific use cases, then you might be able to make reasonable higher-level guesses about intent (though as with normal compilers, you'd need support for advanced developers to work around those assumptions).
I usually snark on Node.js but not really in this case, I understand well when the platform imposes a moat and it's easier to just re-do than integrate. Ain't nobody got time for that... it's still something of a tragedy but it's not something we have an easy fix for.
So some new "things computers can do" from the last 20 years:
- Fit in our pockets
- Communicate wirelessly between any two major population centers on the planet, with high bandwidth
- Store exabytes of data
- Do excellent pattern-matching of all sorts of data
- Be close to your customers, wherever they are on the planet, without you needing to have a ton of capital upfront
- Cost as little as $7 while still being compatible with our complex software stacks
- Be powerful enough to run an Electron application
- Monitor your blood glucose levels and deliver the right amount of insulin in real time
Probably a next great milestone is being able to run multiple electron apps in parallel...
Because the real world is like that, there is no possible programming language that is going to prevent the need for "if". Users may think they don't care about that, but the requirements are full of "if".
Loops you don't need to code today - if you don't need too precise a control over execution. If you need real control, you probably need to write the loop instead of just using a comprehension.
Data storage schemas: As databases scale, efficiency of storage start to add up to real money. The user may not care, but the finance people care a great deal.
No, not necessarily, depending on the business requirements. There's already logic programming, for example a language like Prolog. You the programmer input a very high-level description of the rules that your information must follow. The computer figures out all the imperative bits.
I have a chipset that I'd like modeled, and can I have some trivial drivers by next Tuesday?
Modern computers are not trivial. They are probably the most complicated devices on the planet, full of features, edge conditions and screw cases that are not obvious even to very skilled developers. I've done some very fast platform bring-ups and gotten them to ship, projects organized to be very light-weight and agile (in the non-political sense) and it's still many person-years of effort and a bunch of time on the phone with vendor support, discussing chip-level bugs (can that model please include the bugs? That would help a lot!) No talk at all about pleasant abstractions, we need to ship this pile of silicon.
Visual interfaces are for toy programs that spend resources on making pretty illusions of how the world should work. Underneath the pretty glitz are piles of slain dragons and machinery that people take for granted and apparently think can be wished away. That's fine for end-users and application level folks, assuming they can get their jobs done without resorting to breaking the abstractions (and any sufficiently large or long-lived project will). But someone has to worry about memory management, concurrency and synchronization, all the drivers for fucked-up hardware that (say) locks up when you fire data at it too fast, what happens when the file system fills up or that configuration file is mangled by an upgrade. All that nasty stuff that the "drag a blue wire from point A to point B -- see, easy!" doesn't handle, and never will.
On one project we had a clock that would, very occasionally, go backwards in time. It took a calendar year of going back-and-forth with support and ultimately a phone call with the chip architect to figure out the problem (the workaround for the bug was unpleasantly expensive). It's easy to model a clock and come up with a set of expectations. It is much, much harder to make a clock work in the real world. You would not believe how hardfought some of this stuff is, for features that are "trivial".
Visual programming is great when it works -- I've certainly done my share of it -- but we should not mistake ease-of-use in some domains for revolutionizing programming in general, or (worse) expecting the paradigm to work when things get complicated and large.
- dealing with the environment. My program always works perfectly until it moves away from my laptop.
- debugging. If you don't know how to code, good luck to find the error in your system.
- interfacing. Your codeless stuff is going to work fine for everything that it already know. But new stuff are coming. Somebody will need to code for that.
Now I do think that eventually AI will be able to manage all that. And that it will give human a fuzzy codeless experience. But it will take A LOT of time before we get there.
I’ve built lots of applications without code (and teach others how @ https://www.makerpad.co/) one being a mini Netflix ‘clone', Airbnb ‘clone’ and Fiverr ‘clone’.
They may not be able to withstand Netflix level of users and usage but why should every startup/business have to aim for that. It could service hundreds/thousands of users and turnover great revenue for those running it.
The only reason these tutorials are built as 'clones' is to show the features for others to tweak for their own.
while very valuable for learning, i find that folks building thematic maker sites (no code, react/node, rails, etc.) are very biased towards their own way and often haven't made a "real" product built on what they profess.
engineers would be better off using "no code" more often, and non-engineers would be better off learning just enough react, python, etc. to ship something.
otherwise, everything begins to look like a hammer.
They all fail to live up to the hype. I think it's because you have to have a good general understanding of how things work to properly build (and initially test) software.
Wix and squarespace are more than enough for many businesses' needs. AWS has blown through the roof. And more and more people discover what it feels like not to have to worry about hardware and VMs configuration.
ForestAdmin is also a nice case in point, supposing you have the proper stack.
Sure there will always some who need developers, and most "solutions" this far haven't been up to the task. But I definitely wouldn't bet that won't ever be more than enough for most people and use cases.
For this, extensibility (via integrations and proper established languages; definitely not some absurd and ill-conceived "very friendly script language") will be key
Also serverless is arguable more complex for a business person/analyst to grasp than just telling a developer to create something they imagined.
Or serverless is to those same web developers what codeless is to business people.
Edit: also, this is an analogy
I guess eventually a new gen of Excel comes out that can write code without IF, FOR loops, and function calls, but until then it’s safe to say anything writing those statements other than in code is pretty much snake oil.
As for the rest. No-code / low-code solutions don't just pass nice drawings / uml diagram to a gremlins-powered CPU. They rely (and will rely) on code behind the scenes.
Analogy still stands
They compete with Excel, MS Access and possibly WordPress. They're never going to replace actual software development because once the problem domain gets complex enough the person behind the wheel needs pretty much all of the skills of a good software engineer. They're also pretty much all closed platforms so only an idiot would use them to build a product. So they're stuck in the small-scale automation hook.
I still have regrets that I left because it was intellectually stimulating. It's just impossible* to work in a startup culture whilst being a GOOD parent to young children.
* When you can't stay late when needed and your colleagues are picking up the slack it feels like sh!t and makes you feel like a massive shit; especially when said colleagues are amazing about it.
I think OP was overly trying to be critical of popular things.
Wix is a website with database features, having a back end has purpose.
Using Excel as a traditional database is not what Excel does. Excel is often good enough at storing data that people use it like a database.
Anyway this seemed like a Pop Programming article. Lots of Python and coding love, bashing WYSIWYG and Microsoft products.
The other half pretends they are not, while frantically trying to migrate from it with a various degree of success.
[1] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
In other words, if you are making anything with real value that doesn't already exist, you are not going to be able to make it through some kind of WYSIWYG.
On the other hand, just like DSLs are sometimes appropriate, writing a _domain-specific_ WYSIWYG could be appropriate, especially if it's for internal use and not the product itself.
As long as what you’re doing is not Turing complete, I think WYSIWYG has value.
Yes it's still better to have skilled engineers, but they're expensive and hard to find nowadays, and not every company is even capable of hiring them effectively.
No web developer is charmed by the limited capabilities of Wix, but it's good enough for the static website many (if not most) businesses are looking for. A CRUD app made by a low-code platform may be limited in its functionality, but it's often good enough for a typical business need. To say it's doomed to fail is an overstatement.
Services get more fine-grained every year, and composition of these services is where the money will be made in the future. AI might resolve some of the issues with finding the right services for the right use cases & even integrating them.
Custom, home-made services will be a conscious choice, and might be composed of other services that are publicly available or not. Everything else will use off-the-shelf services.
My .02€
What your approach does do is create a system that is easy to parallelize. You want to run on thousands of cores/threads? Make each "person" a thread, and there you go.
The truth is, this space just gets better every year. You can get more and more done with less and less. Sure, you still can't build arbitrary programs without at the very least a general-purpose programming language, but if you can constrain the solution space just a little bit you'd be very surprised at just how far you can get without needing to break out a text editor.
I worked somewhere with a team of engineers who worked in LabView. They used LabView mainly for customized test equipment controllers and recorders and it worked well. They then branched into FPGAs for some straightforward dataflow signal processing and that also worked well. They then decided they were sick of how long it took software engineers to write device drivers for custom hardware and decided to do that in LabView with some tool that could generate C code from LabView. I got pulled into a meeting about it. I asked a couple important questions: how do you insert memory barriers and how can you write code that is ISR safe? It was clear the LabView folks had no idea about any of this. So I launched into a discussion about CPU architecture. They didn't really listen and everything was a hand wave, "LabView does that for you". It was clear they didn't want to hear my thoughts, so I let it go.
Fast forward 6 months and I get a frantic call from a manager if I had "bandwidth" to write a device driver in C for the same card where the LabView team was supposed to have written the driver.
A new project rolled in that didn't meet the expectations of their tooling, and suddenly they had to start writing native code plugins and so forth, and they were totally at sea. They started demanding engineering resources and invasive changes to the product so their test environment could handle the thing with minimal modifications.
I remember telling one particularly obstinate contractor that we were colossally uninterested in writing drivers for their environment, and that he was either going to learn C or lose his contract. I didn't see him again, maybe his management chain told him not to come 'round the software group again, or maybe he learned C and saved the day for his team.