I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x.
My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor:
Imagine you have to pick a bike to go on a trip. You're travelling on a well paved road through the woods. If you take a light & narrow wheeled racing bike, you'll travel much much faster than if you ride a knobbly wheeled mountain bike with suspension, as long as you stay on the road. As soon as you need to go off the road and cut a new path, you are going to wish you had that mountain bike, and the road bike is actually going to make you go much slower or just stop altogether.
So does the "speed bike"/advanced framework make you go faster? Yes, as long as you stay on the road (i.e. constrain your requirements to their feature set). The moment you need to "go off-road" (i.e. do something the framework doesn't do), such tools actually make it difficult or impossible to make progress.
This is why, for a complex applications (most commercial software), I prefer the mountain bike. Yes, it's slower on certain paths, but when we need to "go off-road" I don't slow to a stop.
Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible".
Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is).
I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote!
All you've said is 100% true, but in addition I'd argue that a big part of reason why no-code tools don't get more traction is also just the simple power of habit and the lack of motivation to invest time into learning it. We already know how to build things the traditional way, and all these no-code solutions require learning a lot of new, proprietary interfaces and stuff, playing with it and figuring it out, learning to work around the limitations. Many other tools and frameworks that we choose to use have similar, probably even worse problems, but they're popular so one feels like it's worth the trouble to learn them - just to stay in the game. No code tools on the other hand are proprietary, not very popular and the benefits they give you are just not that significant to a seasoned programmer. In all honesty, I never even gave them a chance.
The trouble with this analogy is that at some point an ATV comes along that’s much faster both on and off the road, but you’re still clinging to x86 because it’s more powerful than the “high level” languages like C.
I generally agree with you, but I also suspect there’s a lot of room to improve the tools and it’s not always obvious when something is a paradigm shift in productivity or a dead end that will only work in tightly constrained use cases.
Reminds me of a similar situation with my technical manager. He’s very dogmatic in that we should never waste time “re-inventing the wheel” (e.g. there’s already a library/tool out there that does X, don’t waste time remaking it). This makes a lot of sense in many business cases, but not always...
I like using this analogy to demonstrate why:
Say we’re designing a race car, and our race car needs wheels.
“Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!”
I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!”
If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)
We used to make this sort of analogy a lot at a web dev place where I once worked. Eventually it got boiled down to a pithy joke: "Ruby on Rails is great, but only if you stay on the Rails!"
What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to.
And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing to the "real" programming language.
Most commercial software is basically information systems, with very standard architectures, and no complexity whatsoever.
At least not business-related complexity. Most complexity in those systems is accidental, exactly due to us using the wrong tools for the job (namely, 3GLs + frameworks), which do not provide the proper level of abstraction for the problem at hand.
Even for a single system, no one should be forced to use a single level of abstraction everywhere. The game industry has been mixing 3GL code and assembly whenever needed since it moved on from assembly. You don't have to stick to one for everything.
The only problem is, it’s actually not a road bike, but a shopping cart. The advertisement is that you can sit and not pedal (when down hill). And it’s not faster in any case.
I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pushed back, instead I proposed we build a domain specific language using Ruby. I already had some trust with my boss... and he was pretty convinced it was going to fail, he had zero faith these smart (but non-technical) users could successfully use it. But he was willing to let me fail. So we tried it, and really surprisingly, they caught on very quickly, and they were producing complex content within a week.
"No Code" solutions are like asking your user to communicate using pictographs. It's possible, but language allows users to communicate in better detail faster. In school I learned how to write, I'm probably not anywhere close to writing a novel. I'm a terrible writer, but I can write an email. Frankly, that get's me pretty far.
I second this. People can go very, very far with simple and sand boxed Domain Specific Languages that are targeted towards the core function.
There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?)
The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow.
Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.
Did you do anything special presentation/interface-wise?
My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.
if you just remember that all the classic unix-editors were used by secretaries/data input persons picked right from the typewriter, that's not surprising at all. What's surprising is that this insight was so fully eradicated by years of IBM/MS/Apple-marketing (except for the lone warehouses still running on IBM mainframes with terminal frontends)...
I’m a programmer with 15 years of professional experience and another 10 as a student and hobbyist before that. My brother is a carpenter by training who was never even the slightest bit interested in programming. Last year, he learned Pine script[1] because he wanted to customize stuff on TradingView.com. Sure, he doesn’t really understand all the details and sometimes asks me for help, but he is able to successfully get the results he wants. I think most people just need sufficient motivation and they’ll get it. I’ve always said that the reason most people don’t learn to program isn’t because they can’t, but because they don’t really have enough reason to put the time and effort in.
Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in.
Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way)
I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all.
"A picture is worth a thousand words..." When doing presentations or writing, I make a lot of effort to visualize what I'm trying to communicate, as it really helps making sense of all the words.
I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.
That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.
I think those with a programming background take terms like "no code" far too literally. For those who've worked in finance IT, you may know of staff who've build incredibly elaborate models in Excel, and then have come to you when they need something that can't be done in Excel.
"No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmers to build a decent prototype of what they're trying to create. They can then take this to their dev team (if they have one) and ask for refinements.
Even if the end result requires a full rebuild, I'd wager the devs would be happier because they wouldn't waste time building something based on vague specifications communicated by a non-technical staff member. They'd have a prototype to work off of, and can ask clarifying questions that will be easier for the stakeholder to answer because they can see where the devs are coming from, instead of simply speaking in abstractions about something that doesn't yet exist.
IMO, Excel was one of the first 'no code' platforms. The first part of my career was taking Excel solutions and turning them into something that could used corporate wide. It was pretty fun because by the time it got to my team, the requirements were pretty well hammered out.
I have spent 5 years on and off in the no code space and IMHO you're almost spot on. Almost all standard enterprise platforms are non complex and can be delivered in no code solutions, requiring maybe 5pc as real code. Failing to acknowledge this is why IT organisations in large enterprises are typically sidelined by shadow IT teams, who often deliver great solutions in Excel and Oracle Apex.
I agree with this, but it also means the hype is overdone, because these "no-code" tools that are gonna "revolutionize the industry" have been here for ages.
For example in the web space, Microsoft took a stab at it with FrontPage since the 90s. WordPress was released in 2003 and sits behind a third of websites [1].
New tools are popping up that are more complex, but IMO that's because people's expectations of a good web experience is also more complex. I am unconvinced that new tools in this space are fundamentally changing it— I think they're just keeping it up with the times.
I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential architectural patterns of software development a novice will paint themselves into a corner before they even know what they are doing, requiring an expert to come in an clean things up.
I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.
Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
I'm compelled to invoke the "Ninety-Ninety" rule when I hear about solutions like that, although I'm sure it works sometimes, in my experience it usually turns out more like this.
The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!
In my experience, "Low Code" is almost always weasel-wording. It's used to describe products that try to be "No Code", but fall short. It's a way of making excuses for everything you can't do, because you can get a "real programmer" to come in and paper over the cracks. Actually writing this code is rarely a pleasant experience, and the learning curve is a cliff that goes straight from "flowchart" to "writing React" (or worse).
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
That is because we've built tools that are good enough for most use cases, and the cases don't actually differ all that much. For every new case however, new software has to be made. It isn't getting any easier, there is just more of it now.
The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.
About 2/3 of software cost is typically maintenance, not original creation. If some RAD-ish tool makes maintenance more difficult, saving time up front doesn't mean a lot, other than maybe as practical prototyping. Maintenance costs include getting new staff familiar with a tool, and the turnover rate is typically around 4 years for developers. Self-taught programmers tend to produce spaghetti systems, in my experience. My first programs were spaghetti, I must say. I was an IT puppy. I short, consider the medium and long-term costs of RAD/code-free tools.
Reminds me of being warned, over 20 years ago, that the viability of my new career as a web developer was in doubt thanks to tools like FrontPage and Dreamweaver.
My dad found himself with a useless MBA in the 80's recession, so retrained as a programmer after I'd already decided that's what I wanted to be when I grew up (not the last time he would steal an idea from me and run with it).
When I was in highschool the fervor over so-called 4th Generation Languages was kicking up and he worried the career might be going away. I wasn't that worried, and I can't recall entirely why I wasn't.
Today I'd say that they will always need mechanics for the robots, but in fact the situation is not even that dire. AI, which I still believe will fail all over again, replaces less than half the code we write - it deals with the decision whether to do something, but not how to accomplish it. And we already know that we're fucking up data management pretty badly. If 40% of my job went away at the wave of a wand (nothing is ever that simple, and it takes a painfully long time to migrate to new systems), we'd have more time to invest in the provenance of data and protecting it once we have it. I'd still be overbooked and our customers would be a little less salty.
Frontpage and Dreamweaver ... never before could you produce so much bad code in so little time. And never before did the person who had to clean it up to have any chance of breaking out of the box and change something hate you so much. Especially if said person was you six month later.
There's no such thing as "no code". There's just interfaces which are more-or-less capable, and more-or-less intuitive. Any time you define a set of instructions for a computer to execute, you are creating code.
We use Scratch at my Girls Who Code club. It requires students to consider branching paths, and data types, and asynchronous execution. It does not require the students to type, but thank god for that, because they're 9 years old and type at approximately 1 words per minute.
Scratch is still code just like Java, and Lego Mindstorm's EV3, and Automator, and IFTTT. Not all of these systems are Turing complete, and each one contains different restrictions in an attempt to stop users from shooting themselves in the foot: Java doesn't have manual memory management, Automator doesn't have conditionals, and IFTTT is limited to a single trigger and action. But there're still code. Users of these tools need to carefully consider input and edge cases, and test and iterate to see if the code is doing what they intended.
IMO, the primary reason "professional programmers" type their code is because once you know what to type, keyboards are fundamentally faster than mice. That's also why Excel power users frequently rely almost entirely on keyboard shortcuts, and why the command line for an experienced user is often faster than a GUI.
---
Edit: BTW, for the same reason that HTML isn't a programming language, I don't consider most "website builders" to be code, even though I do consider IFTTT to be code.
Code in this context means creating instructions for a computer to follow. Laying out elements on a page (which then adapt to different screen sizes based on predefined behavior) is just that, laying out elements.
I don't know about you, but I can feel myself entering a "coding mindset" when I load up IFTTT—it's simpler than writing Javascript to be sure, but it's the same type of brain muscle, and there's no avoiding it.
I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas."
And that's how I view my job as a software developer: clarifying ideas.
Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.
If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible.
There is no secret programmer cabal where we are holding hostage the REAL tools we use to develop software, and we keep them secret and hidden while we fuck around every day.
For someone to develop a "no-code" solution that fits the huge variety of tasks developers are doing every day, they would be a genius in the same vein as Turing. They would be billionaires.
For what it's worth, tools like Webflow (and their CMS feature) are incredibly well-done.
From a front-end development perspective, no code is legitimate and practical today.
From a back-end or business-logic perspective, no code is more difficult because a lot of it is bespoke (except for things like generating a PDF from HTML).
It's not a binary "killer," but it's certainly a smart thing to play with as a programmer. I've saved a ton of time on things like marketing websites and CMS-level work using Webflow. With time and iteration, I'd imagine some pretty neat and powerful stuff will appear.
While I agree with the author, it's only true when speaking of software that requires custom logic.
For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.
I agree with the author in all points about the no-code movement and goals, but disagree with the larger points about software development and engineering in the business setting.
In particular, the attractiveness of no-code should not be that one does not have to have in-house software development, but that one has less technical debt and thus smaller technical interest payments. Businesses will always have problems with computers, because computers are rigid and unyielding, while businesspeople are soft and compromising.
It is all to easy to read the beginning few paragraphs as the sourest of grapes: The businessperson, having embraced fax, email, paperless, Web, and mobile, is nonetheless no closer to having embraced computer. The "traditional sense" of creating software is derided as "expensive, in short supply, and fundamentally [not quick at] produc[ing] things." But that is all explained neatly by market forces: Developers are expensive because competency is rare because understanding is low because computerizing is a painful commitment because operationalizing a business is equivalent to automating it away. Computers reveal the rent-seeking and capitalization simply by being themselves on their own.
While everyone is right that a "no code" platform cannot replace all developers, if you take away the extreme framing, there is an interesting trend occurring. These days, business power users can accomplish a lot with tools like Excel (this one was always true), Google Forms, Salesforce, Airtable, Looker, and so on. People can define entities, custom fields, workflows, reports... things that used to be feature requests for developers.
Of course, many developers have had the experience of having to come in and deal with some insane Excel spreadsheets, but many of us have also been called into deal with crazy legacy systems built by professional developers. That itself is not an indictment.
As these tools grow, presenting new and lower cost ways of getting a certain class of activities done, I think we would be well served to figure out how to play nicely with these tools. (It's not like we want to spend our time building custom CRUD apps anyway.)
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs.
The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...).
Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
Now we just write complex declarative configuration with no debugging facilities, a non-existent type system, inversion of control that usually ends up working against us and no way to interact with external data apart from stringing everything together with fragile shell scripts. But hey, there's no need to write a single line of Go/Python/Java/Ruby!
- People who are into this stuff know there's something to it, but as a movement, we don't know exactly what it is.
- My personal feeling is that any no-code tool should be useful enough that I would use it. I want some no-code to make me feel for my career a bit.
- The "threat", I think, is very real. For example, whenever I see myself following a set of rules to write software and not thinking, I start to wonder if some abstraction is lurking in there. Maybe the solution is a programming library, but increasingly, I think there's opportunity for this stuff to be more visual.
Why visual?
- UI programming is necessarily visual, and a visual tool for building interfaces makes sense
- Tools around managing software development. GitHub is IMO a no-code tool. VSCode is. Many IDEs are.
Why not visual? Algorithms and business logic. Like the author, I'm unconvinced that flow diagrams will provide enough flexibility to be useful for all but the simplest cases.
I guess my feelings aren't that different from the author's but I think the difference is I'm optimistic that the movement will be generative.
We sell an integration platform-as-a-service[1] and it offers a 'low code' visual environment to stitch together integrations.
But from pretty much the start, we built-in support to drop down to Javascript to build logic and we think we hit a sweet spot there.
You can visually string together most components but drop in a bit of script to concisely define some hairy transformation or complex logic.
These kinds of low code environment are great for doing customizations or enhancements or integrating many things together. It's very much not an optimal solution for building entire applications or software solutions.
There's also the issue of tooling. There's a huge amount of infrastructure built around maintaining large application code bases (version control, merging, diffing). If you want to build large pieces of software in a no-code environment you still need all of those tools - except they don't exist and are non-standard.
The quote that sticks with me is "New Blocks means new builders".
I'm pretty sure this new 'movement' will gain a lot of steam. Probally mostly because of the 'no developer'-dreams.
But the most value I find, is when working with very structured people - who understand data AND LOGIC - but doesn't know how to code. They do not have to write a spec, but can instead make a working prototype pretty quickly.
I actually think the biggest change from earlier on, is that the 'No-Code' doesn't seems to be a dead-end. As it has been earlier.
If you grow out of the No-Code tools, it possible to replace parts of the No-Code expirience using microservices and serverless.
[+] [-] sequoia|6 years ago|reply
My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor:
Imagine you have to pick a bike to go on a trip. You're travelling on a well paved road through the woods. If you take a light & narrow wheeled racing bike, you'll travel much much faster than if you ride a knobbly wheeled mountain bike with suspension, as long as you stay on the road. As soon as you need to go off the road and cut a new path, you are going to wish you had that mountain bike, and the road bike is actually going to make you go much slower or just stop altogether.
So does the "speed bike"/advanced framework make you go faster? Yes, as long as you stay on the road (i.e. constrain your requirements to their feature set). The moment you need to "go off-road" (i.e. do something the framework doesn't do), such tools actually make it difficult or impossible to make progress.
This is why, for a complex applications (most commercial software), I prefer the mountain bike. Yes, it's slower on certain paths, but when we need to "go off-road" I don't slow to a stop.
[+] [-] smhenderson|6 years ago|reply
Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is).
I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote!
http://www.vb.mvps.org/hardweb/hardbook.htm
[+] [-] ivanhoe|6 years ago|reply
[+] [-] gonehome|6 years ago|reply
I generally agree with you, but I also suspect there’s a lot of room to improve the tools and it’s not always obvious when something is a paradigm shift in productivity or a dead end that will only work in tightly constrained use cases.
[+] [-] Rury|6 years ago|reply
I like using this analogy to demonstrate why:
Say we’re designing a race car, and our race car needs wheels.
“Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!”
I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!”
If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)
[+] [-] ngoel36|6 years ago|reply
[+] [-] leggomylibro|6 years ago|reply
[+] [-] K0SM0S|6 years ago|reply
[1]: https://youtu.be/uNjxe8ShM-8 (Nerding out should always be hilarious like that!)
[2]: Recording of a guest lecture he gave for the Esoteric Programming Languages course at CMU. (~1h) https://youtu.be/_3loq22TxSc
[+] [-] AnimalMuppet|6 years ago|reply
And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing to the "real" programming language.
[+] [-] dlwdlw|6 years ago|reply
[+] [-] abstratt|6 years ago|reply
At least not business-related complexity. Most complexity in those systems is accidental, exactly due to us using the wrong tools for the job (namely, 3GLs + frameworks), which do not provide the proper level of abstraction for the problem at hand.
Even for a single system, no one should be forced to use a single level of abstraction everywhere. The game industry has been mixing 3GL code and assembly whenever needed since it moved on from assembly. You don't have to stick to one for everything.
[+] [-] Aperocky|6 years ago|reply
[+] [-] swalsh|6 years ago|reply
"No Code" solutions are like asking your user to communicate using pictographs. It's possible, but language allows users to communicate in better detail faster. In school I learned how to write, I'm probably not anywhere close to writing a novel. I'm a terrible writer, but I can write an email. Frankly, that get's me pretty far.
[+] [-] vsskanth|6 years ago|reply
There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?)
The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow.
Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.
[+] [-] detaro|6 years ago|reply
My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.
[+] [-] fock|6 years ago|reply
[+] [-] dkersten|6 years ago|reply
Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in.
Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way)
I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all.
[1] https://www.tradingview.com/pine-script-docs/en/v4/index.htm...
[+] [-] ako|6 years ago|reply
I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.
[+] [-] pklee|6 years ago|reply
[+] [-] rchaud|6 years ago|reply
"No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmers to build a decent prototype of what they're trying to create. They can then take this to their dev team (if they have one) and ask for refinements.
Even if the end result requires a full rebuild, I'd wager the devs would be happier because they wouldn't waste time building something based on vague specifications communicated by a non-technical staff member. They'd have a prototype to work off of, and can ask clarifying questions that will be easier for the stakeholder to answer because they can see where the devs are coming from, instead of simply speaking in abstractions about something that doesn't yet exist.
[+] [-] matwood|6 years ago|reply
[+] [-] flarg|6 years ago|reply
[+] [-] aylmao|6 years ago|reply
For example in the web space, Microsoft took a stab at it with FrontPage since the 90s. WordPress was released in 2003 and sits behind a third of websites [1].
New tools are popping up that are more complex, but IMO that's because people's expectations of a good web experience is also more complex. I am unconvinced that new tools in this space are fundamentally changing it— I think they're just keeping it up with the times.
[1]: https://wordpress.org/news/2019/03/one-third-of-the-web/
[+] [-] coffee|6 years ago|reply
Agreed. Poor term. But what these platforms can accomplish is liberating for those who can't code yet want to get something live on their own.
[+] [-] mikece|6 years ago|reply
[+] [-] osullivj|6 years ago|reply
[1] https://en.wikipedia.org/wiki/The_Last_One_(software)
[+] [-] arethuza|6 years ago|reply
[+] [-] mmerlin|6 years ago|reply
Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
[+] [-] yebyen|6 years ago|reply
The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!
[+] [-] meredydd|6 years ago|reply
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
[+] [-] satanspastaroll|6 years ago|reply
The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.
[+] [-] tabtab|6 years ago|reply
[+] [-] logicIsTruth|6 years ago|reply
WordPress is great for low code.
I did my html and in an hour had it working with WordPress.
[+] [-] chrisweekly|6 years ago|reply
[+] [-] hinkley|6 years ago|reply
When I was in highschool the fervor over so-called 4th Generation Languages was kicking up and he worried the career might be going away. I wasn't that worried, and I can't recall entirely why I wasn't.
Today I'd say that they will always need mechanics for the robots, but in fact the situation is not even that dire. AI, which I still believe will fail all over again, replaces less than half the code we write - it deals with the decision whether to do something, but not how to accomplish it. And we already know that we're fucking up data management pretty badly. If 40% of my job went away at the wave of a wand (nothing is ever that simple, and it takes a painfully long time to migrate to new systems), we'd have more time to invest in the provenance of data and protecting it once we have it. I'd still be overbooked and our customers would be a little less salty.
[+] [-] sgift|6 years ago|reply
[+] [-] Wowfunhappy|6 years ago|reply
We use Scratch at my Girls Who Code club. It requires students to consider branching paths, and data types, and asynchronous execution. It does not require the students to type, but thank god for that, because they're 9 years old and type at approximately 1 words per minute.
Scratch is still code just like Java, and Lego Mindstorm's EV3, and Automator, and IFTTT. Not all of these systems are Turing complete, and each one contains different restrictions in an attempt to stop users from shooting themselves in the foot: Java doesn't have manual memory management, Automator doesn't have conditionals, and IFTTT is limited to a single trigger and action. But there're still code. Users of these tools need to carefully consider input and edge cases, and test and iterate to see if the code is doing what they intended.
IMO, the primary reason "professional programmers" type their code is because once you know what to type, keyboards are fundamentally faster than mice. That's also why Excel power users frequently rely almost entirely on keyboard shortcuts, and why the command line for an experienced user is often faster than a GUI.
---
Edit: BTW, for the same reason that HTML isn't a programming language, I don't consider most "website builders" to be code, even though I do consider IFTTT to be code.
Code in this context means creating instructions for a computer to follow. Laying out elements on a page (which then adapt to different screen sizes based on predefined behavior) is just that, laying out elements.
I don't know about you, but I can feel myself entering a "coding mindset" when I load up IFTTT—it's simpler than writing Javascript to be sure, but it's the same type of brain muscle, and there's no avoiding it.
[+] [-] heinrich5991|6 years ago|reply
[+] [-] emilecantin|6 years ago|reply
And that's how I view my job as a software developer: clarifying ideas.
Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.
[+] [-] honkycat|6 years ago|reply
If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible.
There is no secret programmer cabal where we are holding hostage the REAL tools we use to develop software, and we keep them secret and hidden while we fuck around every day.
For someone to develop a "no-code" solution that fits the huge variety of tasks developers are doing every day, they would be a genius in the same vein as Turing. They would be billionaires.
[+] [-] rglover|6 years ago|reply
From a front-end development perspective, no code is legitimate and practical today.
From a back-end or business-logic perspective, no code is more difficult because a lot of it is bespoke (except for things like generating a PDF from HTML).
It's not a binary "killer," but it's certainly a smart thing to play with as a programmer. I've saved a ton of time on things like marketing websites and CMS-level work using Webflow. With time and iteration, I'd imagine some pretty neat and powerful stuff will appear.
Read: don't be naive/stubborn; give it a try.
[+] [-] Eikon|6 years ago|reply
For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.
[+] [-] lidHanteyk|6 years ago|reply
In particular, the attractiveness of no-code should not be that one does not have to have in-house software development, but that one has less technical debt and thus smaller technical interest payments. Businesses will always have problems with computers, because computers are rigid and unyielding, while businesspeople are soft and compromising.
It is all to easy to read the beginning few paragraphs as the sourest of grapes: The businessperson, having embraced fax, email, paperless, Web, and mobile, is nonetheless no closer to having embraced computer. The "traditional sense" of creating software is derided as "expensive, in short supply, and fundamentally [not quick at] produc[ing] things." But that is all explained neatly by market forces: Developers are expensive because competency is rare because understanding is low because computerizing is a painful commitment because operationalizing a business is equivalent to automating it away. Computers reveal the rent-seeking and capitalization simply by being themselves on their own.
[+] [-] neilwilson|6 years ago|reply
https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
Read and inwardly digest
[+] [-] mellosouls|6 years ago|reply
I note there is - strangely - no corresponding "Citizen Management Consultant" role.
https://www.gartner.com/en/information-technology/glossary/c...
[+] [-] satyrnein|6 years ago|reply
Of course, many developers have had the experience of having to come in and deal with some insane Excel spreadsheets, but many of us have also been called into deal with crazy legacy systems built by professional developers. That itself is not an indictment.
As these tools grow, presenting new and lower cost ways of getting a certain class of activities done, I think we would be well served to figure out how to play nicely with these tools. (It's not like we want to spend our time building custom CRUD apps anyway.)
[+] [-] q3k|6 years ago|reply
The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...).
Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
Now we just write complex declarative configuration with no debugging facilities, a non-existent type system, inversion of control that usually ends up working against us and no way to interact with external data apart from stringing everything together with fragile shell scripts. But hey, there's no need to write a single line of Go/Python/Java/Ruby!
[+] [-] markmiro|6 years ago|reply
- People who are into this stuff know there's something to it, but as a movement, we don't know exactly what it is.
- My personal feeling is that any no-code tool should be useful enough that I would use it. I want some no-code to make me feel for my career a bit.
- The "threat", I think, is very real. For example, whenever I see myself following a set of rules to write software and not thinking, I start to wonder if some abstraction is lurking in there. Maybe the solution is a programming library, but increasingly, I think there's opportunity for this stuff to be more visual.
Why visual?
- UI programming is necessarily visual, and a visual tool for building interfaces makes sense
- Tools around managing software development. GitHub is IMO a no-code tool. VSCode is. Many IDEs are.
Why not visual? Algorithms and business logic. Like the author, I'm unconvinced that flow diagrams will provide enough flexibility to be useful for all but the simplest cases.
I guess my feelings aren't that different from the author's but I think the difference is I'm optimistic that the movement will be generative.
[+] [-] statictype|6 years ago|reply
We sell an integration platform-as-a-service[1] and it offers a 'low code' visual environment to stitch together integrations.
But from pretty much the start, we built-in support to drop down to Javascript to build logic and we think we hit a sweet spot there.
You can visually string together most components but drop in a bit of script to concisely define some hairy transformation or complex logic.
These kinds of low code environment are great for doing customizations or enhancements or integrating many things together. It's very much not an optimal solution for building entire applications or software solutions.
There's also the issue of tooling. There's a huge amount of infrastructure built around maintaining large application code bases (version control, merging, diffing). If you want to build large pieces of software in a no-code environment you still need all of those tools - except they don't exist and are non-standard.
[1] https://lucyinthesky.io
[+] [-] nslindtner|6 years ago|reply
I'm pretty sure this new 'movement' will gain a lot of steam. Probally mostly because of the 'no developer'-dreams.
But the most value I find, is when working with very structured people - who understand data AND LOGIC - but doesn't know how to code. They do not have to write a spec, but can instead make a working prototype pretty quickly.
I actually think the biggest change from earlier on, is that the 'No-Code' doesn't seems to be a dead-end. As it has been earlier.
If you grow out of the No-Code tools, it possible to replace parts of the No-Code expirience using microservices and serverless.