just let him be 🤣. Hes trying to speak in a subject that he has no idea about . Lets call it low level coding = 0 coding High coding means a lot of coding 😎
Um no. Most serious data products are built by experienced data scientists, a discipline with practices and principles going back to the pen and paper only era. Much care is taken to organize the work and the assumption that error is present is the guiding principle.
Low-Code Node.js Builder Easily to create node.js application and download node.js source code. If you are looking for a tool to create a node.js application for - Use for learning - Use for creating custom programs. - Use for creating programs to sell. - Easy to use, designed to be suitable for beginners or those who are not good at programming. * Free to use * Inform us of the desired program. We will create an Application template for use in the future. . Try to Create Node.js Application builder.impleplus.com Web site www.impleplus.com/en More Functions & Futures (Document) www.impleplus.com/document?id=54501446-e05d-4d5d-8807-ff7087659645
After falling for the "nocode/lowcode lie", that you can "building anything you can imagine without writing code", I abandoned programming and started to look into nocode tools, at first I was amazed and extremely happy that I'll finally be able to launch products without having to spend months bashing my head against the keyboard, trying to find why it doesn't work the way it should. Fast forward 3 months I'm back to coding, I have a slight disgust every time I hear about nocode/lowcode, and it's going to take A LOT for a nocode/lowcode platform to convince me to give it a try in the future. Long story short, of course it was all a lie, I couldn't "build anything you can imagine", I could barely build anything in fact. I built on 6 nocode platforms (glide, bubble, adalo, appgyver, flutterflow, backendless), and looked into many more, none of them were able to build a serious high quality, complex software product. Some of them came with a predefined user interface and didn't allow you to edit it (wtf?!), some of them straight up lacked basic functionality (seriously how tf am I supposed to "build the next airbnb" if can't even make an element invisible...), some of them were so complicated and hard to use that it would've been easier just to write code (oh, the irony) and some of them straight up didn't even work ("where was an error processing your request please try again later" yeah thanks bro) . So in conclusion, don't do the same mistakes I did, lowcode/nocode is okay if you want a small little app for an MVP or to impress your mom and you have no intention of learning to code. But if you already know how to code and/or want to build a serious software project, stay as far away from nocode as possible.
I don't think the real answer is so black and white. And a lot of these tools are still pretty immature and they are getting better. It really depends on what you are tying to build. Sometimes it is good match and sometimes it isn't. I think the issue is a perception and expectations issues, especially with management and sales. It is often sold as so easy that even business users can build their own apps, which is mostly a lie. Management also falls for the lie that you will get an x2-x3 faster app development with no real drawback. The drawbacks exist, but some that exist now, especially the good ones allow to also use real .js or java when the tool is limited. You often need real programmers or highly technical people to write the exception cases and weird interfaces or whenever real code is needed. Also all of these tools vary a lot in quality. Some are quite poor like EdorasOne and Flowable while Saleforce is much better designed and allow easy use of real code when needed.
I've been working in the IT Industry for 30+ years now (started when I was 18!). About every 4-5 years a wave of low-code/no-code solutions appears and each time they claim that programmers will be made obsolete and companies will no longer need to hire coders. There are very slick demos that seem to magically enable average business users to create data entry screens and generate reports without writing nary a line of code. This tools are scripted demos with limited application to providing solutions for the real world. As soon as the user tries to do anything off script, it is either not possible, or needs a developer who understands the underlying data (and SQL) to get the data that the user desires. The data entry screens are usually very generic and apply little validation on field input except for perhaps a static mask. The tools are very limited. After being through many cycles of these types of claims over the years, I now ignore the hype and give it little notice.
I totally agree. This is just an attempt to keep salaries down for programmers. If companies want more automation, lets start to automate off the shit programmers aren't even supposed to do: like tedious manual deployment procedures. Administrating Jira tickets..
You’re right, this AlphaCode thing reminds me of the beginnings of the 2010’s when the "Site Builders" like WIX, emerged..."is the end of webdesigners" they said...lol, from 2013 to nowadays the demand for frontend developers is greater than ever...cause tools are just tools in software process development...
Since Clipper 87 I see people falling to this idea. It's perfect until you need to evolve it or fix it. I used to try to reason with the customer before was too late, but most of the time was useless.
I was at the same point till I saw Power Platform. If we look at Power Apps, it's one environment where you can build complex app with low code, as the platform provides many out of the box features. It requires very less code, only to customise when required, but for most part it's a no code solution development environment, which is also responsive.
I've met plenty of academics who could code just fine, but weren't great developers. I've known business analysts who could do things with SQL just fine, but they struggled with engineering the flow of communication between critical parts of the system. Even if my IDE could write my code for me on my current project, there's more going on in the aircraft than the code inside one part of the system. There are so many different sensors, comms systems, and other things that make it difficult for me to imagine no-code or copilot style software is capable of envisioning a solution that the customer actually wants for complicated systems like aircraft, large games, exchange systems, etc. At my last job, I ran into a wall of project managers and C level execs who were trying to push Microsoft PowerApps for more and more client facing solutions. I didn't stick around for the result, but last I heard, the client wasn't happy with the end product. There will always be a need for software engineers for as long as computers exist in their current form.
I used to work with a mathematician and the software models he produced were a bizarre mix of the most advanced constructs in the language but with virtually zero style or understanding of memory management. Fortunately, that's not a problem when it's just a model.🤣
The irony... the truck driver says trucks will never be fully automated. As fast as tech moves in the development arena vs autos-id say there's an equal chance both become obsolete around the same time
@@raulsanches3619 That's because truck rivers are not engineers, and personally I think they are partially right for the near future. I think you can make self driving trucks on predictable environments like developed, maintained highways in developed countries. The story changes when going into countryside narrow, no-lanes, muddy roads, or high crowded chaotic roads in places like third world countries. We will wait and see anyway ....
I've been experimenting with Github Co-Pilot lately and I think it has far more potential than any of the Low-Code platforms to be useful. I don't think it's going to replace developers, but I think it will definitely help us deal with certain tedious tasks much more easily (I've found it's particularly good at helping with boilerplate, filling in unit tests and helping write documentation)
Do you think making it easier to write code that would otherwise be tedious it can store up trouble by helping developers write lots of code that's going to have to read many times in future? Maybe without the co-pilot devs would have had to do something more succinct and perhaps easier to read in the first place. Although I know succinctness and ease of reading are certainly not always correlated.
@@barneylaurance1865 I'm not sure that's a Co-Pilot issue tho? At the end of the day, the existence of boilerplate is not exactly something you can lay at the door of Co-Pilot :-) To be honest, I've seen plenty of terribly verbose code written with no ML intervention whatsoever, so I'm not sure this will change... To clarify on the topic of tedious code, maybe I should give an example of Co-Pilot working well. I was writing some unit tests that were processing a fixture data structure reflecting the result of call to an API. After writing an assertion that some value within a map was correct following processing of the fixture when starting the next assertion it seems like Co-Pilot had processed both the test I was writing along with the fixture data and correctly suggested the next assertion I wanted. For me, that was pretty useful :-) I think on a more general scale, Co-Pilot will be more useful for people working in dynamic languages like Python where suggestion capabilities are more limited. For people working in static languages it's going to be less useful, although not useless. It's general capability of generating suggestions based on your codebase is generally useful, I think...
I am currently working on a project where we had a low code/'no code' environment. Now I have to port everything into a mixture of C++ and Python because the 'no code' version was way too slow, resource-heavy and some features would spontaneously stop working. I don't think that programming jobs will be affected that badly. Because libraries literally do the same thing as 'low code' environments. You do not have to code them yourself and we all still have our jobs.
Excellent content as always, Dave! I used to work for a company that drank the low-code kool-aid and ended up migrating to custom code (due to extremely slow turn-around time to crank out new features, poor debugging/testing support, and unexplained performance issues) and never looked back. As for the job security threat non-sense, programmers are still needed to pick up the pieces whenever low-code systems blow up, so don't panic.
I have some experience with low code development with one of the large (largest?) low code platforms, in a legal context. The best summary I have, I credit to a colleague: "It's great for rapid prototyping." From my perspective, it was just like any other tool in engineering: you end up replacing one problem with another; you're shifting the complexity around, rather than fundamentally reducing it. Biggest problems we had was around architecture and lifecycle management. Unlike (usually) .NET or Java (or dynamically linked C/C++), when the platform needed updating, the application needed to be rebuilt - and therefore retested. There were also architecture problems - because the app had been developed by non-programmers, they didn't have the understanding/appreciation/experience of how *GOD AWFUL* ORMs can be and the dangers of accidentally slurping vast quantities of data over the network. There were also other issues - bugs that couldn't be diagnosed and corrected by someone who understood lower-level HTTP/HTML and Java (yes, me... And I *loathe* Java 😂) Another MAJOR downside was the cost - the infrastructure was EXPENSIVE, *plus* we had lawyers writing software... Essentially, we ended up with untestable, poorly functioning software, written by amateurs that was extremely expensive to develop and run... And a bloody *nightmare* to maintain! It was great for the lawyers, because they had the sense of involvement, control and progress (all the things lawyers are predisposed to), but the cost of delivery was insane - it would have been FAR cheaper to employ a couple of good/experienced devs full-time and use cheaper infrastructure (even public cloud...) Like I said, it would be good for prototyping: let the lawyers sketch-out something that kinda does what they want, but then had it over to experienced devs to "build properly".
COBOL was developed to be the language that would cut software developers out of the loop and allow businessmen to write their own software. I would imagine the same will happen with this no code / low code fad, same as in the early 2000s when WYSIWYG editors were this huge fad and look how well that turned out.
@@henkvanboeijen7643 it was? the syntax quickly gets complicated past simple stuff. but i guess i could see how the wordiness was meant to be a low barrier
@xybersurfer I have absolutely no problem with oracle SQL. Works fine for me, even with very complex queries and scripts. If you want to do something complex it's going to be freaking complex no matter what language or tool you use. It's actually datastage that I have a problem with, not sql. That archaic ETL tool is really inefficient and can get on your nerves 😂
Hi Dave, I'm a developer advocate for a low code development language and your videos have served me well in demonstrating to developers that they are not going to burst into flames and low code development is the same as traditional development from a problem solving perspective. The advantage of the low code development tool I use is just an abstraction layer, NOT for problem solving that stays the same, but for the repetitive, dull, tasks of writing the code in a specific language itself. For example, I develop using the same tool independently of where this code will end up, i.e. JavaScript for the client side and C# for the server side, of course I'm very ware which is which but I code the same way. Every single method I create, their calls will be automatically logged and timed for performance. Calling a server side method from the client side is just a simple "low code" call that gets implemented as a secured REST call to a server method with all parameter parsing so the client side can send and receive the result. This is the power of low code. The use case this tool covers is web development. Sufficiently broad to support the development of a banking b2c app, REST API’s or Wordle, making the problem domain far from well known. It does support version control, debugging, logging, testing, modularity, cohesion, abstraction and information hiding, also CI/CD but only very short lived branching. From my perspective it checks all your boxes from this episode and most from your previous videos. So here is my hypothesis, I believe you haven't been exposed to low code generic development tools that can create applications for generic use and those applications can technically live outside of the platforms that created them. Would you like to do this experiment privately?
No-code solutions scared me when I was earlier in my career because I thought that they would make me replaceable. I now understand that software engineering is about managing complexity and enabling change over time. Low code tools don't really introduce any new or compelling solutions to either of those problems. All of that said: writing code isn't intrinsically valuable, it's just one approach to solving problems. If you can solve problems with less code then that's probably a win.
There will be a day when NO CODE will be a very good option. The engineers will design a AI that will ask for inputs, limits, exec.. and Write the code for you.. The AI will have the main asset form software engineers, and that is their "Problem Solving Skills." Once that happens being a software coder will be something left for a AI program that will most likely be cloud based. I am sure there will still be a need for programmers, but that need will be much less. We are at the beginning of workable AI revolution and I am sure it will be integrated in every aspect of our life. We could be 5 years away or 50 years away, but i guess is something like 15-25 years. Hints of it are already starting to show up.
Maybe. A lot of working in software is managing the stakeholder when their idea is impossible or just bad. I wonder what that looks like in an AI-powered software development world
When I was in school in the 80s, one things was said about software development was that coding itself only accounted for about 5% of the development effort. I expect that number is even smaller today. As you point out, the actual task to solving a problem. That task is not addressed by any of the low code solutions I have seen when they arrive every few years or so. I remember the first one was a tool where you didn't write code, you connected functional blocks together. Many were worried about that. i figured that was great, but that someone was going be needed to write the new blocks as new capabilities were required. Most low code fits this model. At this point, I see no chance that my job will be eliminated before I am ready to retire.
My problem with low code / no code is that even if it seems like it solves your problem you are then setting the client up for failure in the future. Most of these solutions are small companies that might not last long, and usually they want to host the solution in someway. Plus by the time you bump into the edges of the system the client is already deeply invested in it. So it would have to provide such great value in the short term that it wouldn't be all cancelled out with the costs of migrating away from it after a certain point.
Hey, Matthew Harris, We are also 20 years old small company. Have also created many successful story. Would like to share our details privately. Let us know when can we connect.
Great talk and communication too. And an open-mindedness I would never have. You are pointing the real great problem of no-code: no-code means no code lifecycle management. And that's a source of disaster. I always find my team importing stuff from Production to realign things in Development, or redeveloping things after being released to adjust small bits here and there. Also, the no mistakes allowed philosophy really bugges me. If I develop an unnecessary component and release it by mistake, some no-code tools under certain conditions will never allow me to remove it. During my work days I find myself saying "Were it code, this wouldn't happen" too often.
I'm in charge if product management for a data driven business application used nationwide with complex role based functionality. I couldn't be where I am without low code. I also couldn't be here without complementary custom development. These two things are not mutually exclusive. They are AND, not OR.
Excellent talk. I really enjoyed a) the fact that the mid roll advert was for a "no code solution" b) the use of examples from your own experience (sometimes you can be very theoretical and I find it helps to illuminate the subject you're talking about) and c) this being a dive into a bit of a side subject, something we come across but don't necessarily have the time to dig into personally. Good work
Great video that agreed with my experience. Excel is a great low code tool for business people. It is really powerful. I had the misfortune to work on an application written in Excel and VBA. No testing no version control and global variable hell. Not only that the developers working on this needed file locking and the ability to perform timezone conversion. This is where excel started to unravel. So the company wrote excel hacks to achieve this and wondered why things went haywire when their custom file system locking was failing. Sometimes you move away from the well defined area low code is good at and you end up having to reinvent the wheel. The discussions about the performance were also challenging. The developers expected to have infinite file system performance and infinite network bandwidth. When the network was saturated with dir data their application state ended up being corrupted due to no checkpoints or property error handling. Rubber bands and sticky tape holding it together.
I prefer to look at low-code for what it's good for: a way to quickly develop a working prototype and modify it as we work out the problem domain. Sometimes the edge cases haven't all been worked out, sometimes the problem isn't obvious, and only when you put in operation do you see where the hiccups in the processes are. This would be fairly common in small businesses and operations, I think.
No code/Low code has already taken over. If you are a java developer, you are highly likely to use the Spring Framework, which has taken over lots of boiler plate aspects and you are just hooking up your custom code. This means it take a fewer developer to code up a java project than it used to be in the pre-Spring Framework days. Coding will not be lost, but the problem domain will shift to a higher level. Probably, machine learning.
Great video. I once saw a presenter at a conference expressing pride that his solution looks like the wiring diagram for the space shuttle. That's a bug, not a feature and I pity the person who has to maintain that 'code'.
I've heard this one before. Back in the early/mid 1990's we had CASE tools that were going to revolutionize software development. It was a bunch of vapor that just went "poof!"
I don't think low code/no code solutions could ever truly replace programming jobs. After all, programming at its core is nothing more but a way to formally specify our requirements on behavior and a programmer's job is translating highly-abstract human-level wishes and desires into highly formal computer-level specification. Until we have human-level AI that can understand human intention and translate it into machine code, programmers will be needed to do that translation. Higher-level languages can certainly be useful since they allow us to combine "pre-packaged" formalizations and not do all the nitty-gritty details each time, but at the end of the day, the rubber has to meet the road somewhere. It seems to me that low code/no code might certainly be useful if our use case is so common that those "pre-packged" formalizations are feasible to define on a very high abstraction level, but I think that ultimatetly they'll likely end up as just another tool that can make programmer's life easier. There are simply too many problems to be solved for the super-high-level abstractions to be flexible enough--as evidenced by what you've mentioned in your video about the trade-off between the system's flexibility and the solution looking more and more like code.
Wordpress, wix, squarespace etc didn't replaced web developer jobs, instead tools like wordpress by allowing everyone to have a website, indirectly promoted new markets for developers to develop custom themes, plugins etc.
A key drawback of general purpose low-code solutions is that while they can successfully abstract away the complexity of the general problem, they cannot abstract away the complexity of the specific problems that an organisation may want to solve. An organisation of any significant size almost certainly has more organisation specific complexity than general complexity. A hybrid model of code and low-code can be quite successful in my experience. In such a model, software developers build out functions/services/interfaces that abstract general problems (ie. talking to a database, sending an email) to higher level organisation specific concepts (ie. notifying all staff in a division) using good old fashioned software development and code. Non-developers can then build low-code apps/content using these systems which are framed in organisation specific language and concepts.
As a tester, welcome developers to the "automated" discussion. We've been engaged in this for a long time and I can't see automated development being a thing either. You could replace "low code/no code" with test automation in this video quite easily, as well as AI/ML as others have mentioned. Even down to the part of grandiose tools marketed by vendors etc. We've been here before and for quite a while!
The philosophy of No Code is fundamentally one of empowerment. It is enabling people without coding skills to be creative in the same way developers are. Such systems have been around for some time, spreadsheets being an example of pervasive tools. There is of course an overlap; even Excel has expanded from allowing expressions to full on languages in cells. But the core philosophy is to empower people disenfranchised from the act of creation through because of barrier of technology.
That’s a little bit like saying that copy-pasting clip art is empowering to people who don’t know how to paint. It is in a sense, but you’re ultimately still very limited.
@@davew2040xLuckily my case isn't for replacing all application development with no code tools. It is the case however that the current microservice philosophy and domain driven development actually promotes domain binding rather than making software more general. No Code or low code is really about domain decoupling, which improves quality and development speed. Yes; it is constraining, so I don't promote these solutions as something that will replace programming.
Outsystems as a low code development platforms enables developers to build enterprise level full stack applications. It provides end to end development features including Devops, Production and Quality assurance. We can now build complex applications within very short time span.
This was experience with a machine vision ide by cognex called cognex designer. It was sold as making it easier to write machine vision systems so you don’t need software developers. It had a flow chart style programming interface. It was great for simple throw away experiments and demos but when it came to real applications managing a spider web of connections between different functions in the graphical interface became overwhelming. Of course it allowed you to write custom code in c# but it didn’t let you write classes, not in the ide you could make these in visual studio but you had to close and reopen cognex designer every time you recompiled. It also packaged all the files up in a zip file they called a cdp. I did use git but it was difficult to understand what change you made caused the issue that you needed to role back for. In the end software developer wrote all the software and the non developers didn’t want to touch it. Management didn’t really seem to understand this.
Thanks for your insights on this topic, big fan! would like to highlight that more sophisticated low code platforms offer code version control capabilities through GIT such as node red, and also automated testing and cli for enabling continuous delivery such as powerapps. however, your comment related to modularity and separation of concerns ponders me how to approach it, perhaps a next step to tackle in the low code systems
This is the most balanced opinion on Low Code that I've seen. It has its uses I'm sure, but I think it's currently being sold to people who frankly don't understand the complexity behind most software, and how that complexity can grow over time. I'm also suspicious of the fact that most of the low-code content on youtube being from salespeople basically, there seems to be no in-depth discussions of the actual pros and cons.
We do not think it will kill jobs - if anything, it will amplify it. As of today, you can only create faster prototypes with nocode, but you cannot completely replace code. We build prototypes all the time.
There will always be programmer jobs in the classic sense. Maybe less of them, but they will be around. *Someone* has to build these tools in the first place for one, and then there will be things those tools just cant get quite right automatically - especially if on time execution requirements are involved (ie displaying frames on any screen)
I've seen very successful projects with robotics process automation (RPA) tools, these also run under the label low code. In most organizations there is much more IT demand than the available IT ressources or IT budget. After prioritization most of the smaller and not so critcal requirements are postponed to the next sprint/budget period/year (multiple times). Some of those day to day problems (mainly copying data from one user interface to another user interface or inserting data from an excel source) could be easily solved by the "business programmers". If you use the right tool, then you also have separation of Dev/Test/Prodution stages with proper tools to transport from one stage to the other. The Business Programmers tried some more complex integrations scenarios but then realized that this probably a job for the IT guys. Overall the organization was able to implement more requirements than before. If programmers feel threatened by these tools, they are probably working on too trivial problems and should step up.
good points again. i've experienced the testing in production issue and the bad documentation. it's interesting that i never considered the lack of control over the configuration of such systems. i'll be checking out your new book, i like the reviews and can always use some wisdom (already ordered a copy)
That's the experience I got from Scratch coding. Assembly of code from blocks seems good until you find all the limitations. However, Deluge (Zoho) is the opposite - highly productive code for business apps.
The thing is people who execute low code or no code platform are mostly( but not entirely) developers. They who use completely understand what the video is trying to make a point and kinda know the limitations of the low code idea. The people saying this gonna replace the traditional coding is the one who never into coding seriously
I have been using Low-Code OutSystems Platform for about 10 years now and although it is based on visual programming and helps abstracts a lot of complexity, we still need to have a developer mindset.
Proprietary database: typically, we have had to buy separate licenses for an isolated test environment. Then find a way to replicate the changes without retyping them.. The licenses can be expensive, and often forced sharing a single test environment for budget reasons. There are "partner" programs that vendors use to help, but these come with their own constraints (cost or minimal resale volume requirement). In one case, the minimal license cost was in the 6 figures and nobody was willing to pay, so warn, ship and let the customer tests it. This is part of Open Source popularity..
Really like your Flynn's Arcade shirt... Excellent talk! What concerns me is that I've seen lost knowledge each time we abstract another level - like robbing those who program or work with tech the experience (maybe pain) where you are forced to learn something you might not have otherwise come to learn and is useful for your development. I've seen this in IT operations as well. Just a thought... but thanks very much nevertheless!
Great video Dave. Could you talk about this use of the word "AI" in our industry? It seems like real AI was promised decades ago and then suddenly people started saying "machine learning" which has now turned into "AI". I feel like many people don't understand that it's not really "AI".
I've been working with a startup for 2 years now. We had our ups and downs but things were going pretty well until recently when he's decided to switch our code base with use PHP, Symfony and mysql to no code/low code. I've told him that it's quite risky what he's trying to do but he didn't want to listen so i've agreed but the more i use the tool ( bubble ) the harder i find to go from a programmer mindset to no code and so i've called him and told him that it would be hard for me with the deadline they are asking when i'm pretty bad with these types of things and since they're still in early stage (startup), i don't want to waste their time (a.k.a money) and i've told him to find someone that is more comfortable with bubble. He felt disappointed somehow. What did i do wrong! (i'm 23 by the way)
I have the displasure of working with a low code platform for developing multiplatform applications at the moment. It's terrible. Nothing works exactly as you expect it to, there are always differences. Most things are hidden behind layers of abstraction which make it more, not less, difficult to work with, simply because it's so different. Half the time I ignore the low-code options and write everything from scratch anyway. I wouldn't recommend starting your career in this field.
Live configuration changes: that is so true. Facebook network engineers would probably agree.. In all systems there is a need for auditing changes (requires logging) and rollback (requires versioning).
Everything old is new again. We've been trying to do this since at least the 80s (and maybe earlier). In my view, things like Excel point the way: low-code solutions just aren't going to look like traditional code at all.
No. But it will also continue to trivialize the task of app making(and programming, in general). People already think that it's super easy and should only take a day to create an enterprise-level app---built, scaled, and secured.
Low code stays limited. It kills maybe the jobs of low salary script kiddies, but the real work is finding a solution to a problem and for every complex problem low code won't be enough.
I agree with pretty much every point made. Here are a few related personal opinions - Sometimes the most practical approach to testing something is to just test it in production, because the functionality being produced is critically needed and the time it would take to produce it effectively otherwise is prohibitive. Biological neuroscience shows fairly conclusively that human cognition is the result of a mechanistic process, so AI cognition can and probably will eventually catch up with and even surpass human cognition. At that point, AI programmers might replace human programmers. But I don't think low code/no code systems ever will, for exactly the reasons presented. I think most people think low/no code solutions will replace programmers on a large scale believe that most significantly different problem domains that are possible or likely to ever exist have been or will someday be thoroughly explored enough to be condensed into no/low code solutions. I sort of think that's a ridiculous idea, because even if all significant problem domains were so thoroughly explored (which by itself seems ridiculous to me) drilling down into the level of "configuration" details that would be required in many, many specific real world instances would more-or-less amount to programming.
First, let me say I love your t-shirts. Yet again, this is a great one. This isn't a comment on this specific video, rather a comment on the ideas you promote in general. My problem isn't any one specific idea, it's that most of the things you promote depend on doing them perfectly 100% of the time, and more importantly, building on other things also being done perfectly. Ironically, you always talk about reducing coupling, but the very ideas you promote are tightly coupled. What do I mean by this? * In order to do CD you need to do CI, have reliable unit tests, have high assurance of correct code, use trunk-based development, do pair programming, do tdd, etc... * In order to do CI you need to have reliable unit tests (I won't say coverage, because we both know that's a useless benchmark) * In order to do CI you need to be able to constant commits and use techniques like feature flags (which are not useful for many kinds of changes, such as database changes that break the alternate paths) * In order to have high assurance of correct code you need to use pair programming (because you can no longer do pull requests due to trunk-based development) * In order to have reliable unit tests, you need to do TDD (otherwise you have tons of issues with useless tests that test implementation) * In order to do TDD you need to write it from scratch as testable (yes, there are techniques to improve code and add tests to legacy code, but that's not really TDD and it takes a very long to for those tests to be useful much less reliable at indicating broken code). And so on, and so on... This seems like there's a huge coupling between all these techniques, take one out and the entire process fails. Which makes it much much harder to incrementally achieve CD, especially if you have a lot of legacy code (like most organizations) that doesn't use those techniques and isn't very testable. My experience, and I have no hard data to support his, is that doing TDD adds about 15-30% more effort up front, but reduces rework by up to 90% on the back end. This is great. But trying to add unit tests after the fact (again, in my experience with no data) is that it can take 50-250% of the original effort for a fraction of the tdd based benefit (unless you end up essentially rewriting the code in a tdd way as part of the refactoring, then you get the full benefit but still at huge cost (closer to that 250% when all is said and done)). I'm not disagreeing that everything you promote, when used together, results in significantly better software. I'm simply wondering if it's truly practical to expect this perfection, and if you're not perfect, everything falls apart anyways. (all too often when someone comments about how this process or another fails it's "You weren't doing it right", which implies not doing it perfectly leads to failure) Sure, perfect is the enemy of good and all that, but why is tight coupling bad for software, but good for software methodology? 250% more effort is a hard sell to management. At that point, you might as well throw the code away and rewrite it from scratch, but that's also a very hard sell, so you end up with only lukewarm support for your entire process, and if you don't get full buy-in what's the point?
Sure, and retrofitting this stuff is more difficult that starting from scratch, but while I agree with the general aim of your comments, I disagree with some of your conclusions. Sure, retro-fitting TDD to an existing codebase is more difficult, so organise things so that new work is possible with TDD, but don't retro-fit to code that you aren't changing. "CI you need to have reliable unit tests" well yes, but if you have 1 reliable test that stops you making a common mistake, that's better than none. Pair programming is a choice, it is not difficult to adopt if people want to do it, so start discussing the reasons why the team might like to try it. I agree that some of this stuff is difficult to change, but it is not impossible, in fact I make a living help companies and teams do that, we almost never get to start from a blank-sheet. Step 1 in solving any problem is identifying that there is a problem, step 2 is coming up with something that may address the problem 3 is trying it out to see if you can make it work. Here I certainly try and help people with steps 1 & 2, the trouble with step 3 is that it is a bit more contextual, but there are plenty of videos here that try to tackle step 3. Checkout my stuff on refactoring, or acceptance testing. The only bit that I disagree with is the assumption behind "250% more effort is hard to sell" - So don't! Don't structure this as "250% more effort" find small changes that you can make that don't really add more effort, they just change where you apply the effort. Make the code that you are working on now, today, a little better. Write new code with tests, and do the work to isolate that new work from the big-balls-of-mud elsewhere so that you can. I think that you get to, what I concede can look like some fantasy Nirvana, by many small, practical steps, not by huge stop-the-world-efforts.
@@ContinuousDelivery I don't disagree that you can improve legacy code, I disagree that you can ultimately achieve the nirvana you describe with most legacy code bases, and this leads managers to think "Just add unit testing and all our problems go away, we don't need a testing department, etc.." My other main argument is that CD as you describe it is not very easy to achieve, and may be impossible with many legacy code bases. You have made it very clear that you don't think it's possible to do CI without trunk-based development, and you have also made it clear that the only way you can do code reviews effectively with trunk-based development is pair programming. I can't place it, but I think you may have even said that the pull request methodology was harmful, because it prevented CI. And this is where i get into the idea that your methodologies are incredibly brittle and coupled, and prone to failure. If not done perfectly to achieve CD. Many of those practices, sure, can be used independently, and they can improve the code. I just don't see how most organizations can achieve your nirvana without starting over. I know it may sound like i'm attacking your positions. I am not. I agree that what you describe can work. I just want you to consider how realistic and effective it is to do in most organizations and most code bases.
@@erikf790 Such a codebase is never going to be pretty, but you can usually make it workable. Most organisations that we think of as good at CD started from a legacy codebase! Amazon used to be a 3 layer PHP & relational database application! Software is infinitely malleable, so the question isn't really "is it possible", its always possible, a better question is "is it worth the effort" and that depends on the system. If you are about to retire it, then "no!". If this is the core of your business, and your business is uncompetitive, then "yes!" and there are lots of shades of grey in between. I know it's a nice thesis, but I don't buy the idea that these ideas are coupled. Yes they are coupled at the limit, but if you have no tests and you add 1 then it's an improvement. It looks coupled when you see a highly optimised, effective version, but the journey is one of lots of independent, parallel, steps.
@@ContinuousDelivery Amazon is probably the worst example you can give. They have almost certainly rewritten their entire code base (perhaps several times) over the years. They also have nearly limitless money to throw at it if they want to. But I've said my peace...
Great observations, Dave. I'm trying to help enterprises understand lcnc and you raise many valid points. The bottom line is that today low code = low engineering so think about the use case and environmental factors. Also a big need for lcnc development is governance to manage tech debt, duplication and data integrity. The route to live needs better QA and operations management too. All things that business users don't ask about and most lcnc vendors address. I'm working with some standards bodies to try and deal with this..are you doing work on this too?
While most of lowcode platforms struggle from all those problems with no version control, tests etc., some of their authors already noticed that. E.g. Microsoft allows their "power platform" solutions to be kept in json file (which can be versioned) and they can be deployed from CD pipeline. This way, I think it's possible to have also a development environment. Although since most of them are used for integration, it's still hard to test them. While you can trigger logic apps/powerautomate manually, I think it's still hard to truly test the trigger (but if you integrate programmatically, e.g. by webhooks, this is true also). Of course, such tools with all that development ecosystem (version control, pipeline, automated tests) will still be too complex for someone not specializing in them, so I predict that "low-code is a new code" and some of us will use them as we currently use any programming language. Just text files will be replaced with diagrams (which I like BTW) The big benefit from them however might be lowering the threshold for beginner. It could be possible that simple applications will be created by business, users etc. and if the application becomes bigger and more valuable, it's creators might start solving the scale issues by learning development tools. Also such an app could be taken over by professional dev and they might gradually improve the development process or the app itself without all the hassle we now have when working with low-quality code
I am pleased, and not surprised, that some low-code systems are trying to address some of these problems. I am sure that we will make progress on this at some point, but people have been trying this for a very long time and it hasn't really worked, except in very specific, very constrained, circumstance (like spreadsheets) and even they suffer the same problems when people inadvertently cross the complexity boundary.
I noticed you never used a no/low code system that was normally designed. They have all elements you mentioned as a version control and a testing site. I could say that an embedded version control is a key feature of any real no code system.
In which case my argument doesn't apply to those types of lo-code systems, but I still think that they are the minority, at least in terms of popularity.
The hateful thing is the vendor snakeoil sales, and then selling the promise to "management" in enterprises who know no better. So many companies trying to go through a digital transformation now, there are rich pickings out there....
As an SDET who worked with the so called low code solutions I can attest that they require more coding/tweaking in order to work than a proper scratch built test harness.
One of the systems I work with was touted as low code. It ended up needing tens of thousands of lines of Javascript (cient and server side) and APIs (C#).
Well, you could count yourself as lucky -- a decade and a half ago it could have been tens of 1000s of lines of XML, XSLT and XQuery -- I have worked on such a "low-code" system and at the time would have been happy to swap it for a Javascript and JSON based system.
Does this all apply to BPM and Salesforce development? Some of the BPM tools I have seen have no automated testing, no source control and a dynamic, but inefficiently created database.
Trust formal specification systems like TLA+ in combination with code generators more than "Low Code/No Code" solutioning like Github autopilot. Additionally, this quote from the 1960s (YT - 9min marker of Auto Worker Hated His Job & Felt Like A Robot. Doesn't See Automation Coming) certainly comes to mind when it comes to automation in the workplace: There are two different kinds of futures - one where everyone will be retrained and will be able to bring their new abilities to the new products and needs; the other which we all fear and must avoid (sic) is that we go on with our program of making more and more things automatically and training scientists and mathematicians who live in a separate world from the mass of the people. And the mass of the people are freed from work but will become less and less interested in the life that they have to live.
I wanted to thank you earlier for this great video, but had to figure out how to trigger the UA-cam API first. Using the plain comment function seems suddenly too ‘low’ 😅
Interesting. What are your thoughts on AI / Neural Networks writing code? There's been chatter about some of them working on confined problems relatively well. I imagine it could be helpful in a few years, e.g. by describing a problem and the computer creates a library that adheres to your defined interfaces to tackle it for you. Of course, and very obviously, the AI may have drawbacks, such as not accounting for every edge case. But in these cases, just like a real developer, you'd adjust your tests (as part of the interface) and the AI will adapt the library to fulfill the new requirements.
I'm on board with your assessment of *existing* low-code solutions. However, while it is difficult _not_ to make said assessment of such systems based on what you've encountered, it's analogous to making assumptions about a group of people based on the only ones you've encountered. To be clear, the low-code concept is not less powerful, it's the current implementations, presumably by people who are attempting to solve the wrong problem.
@@ContinuousDelivery Then, I sincerely apologize for missing it :^) In any case, I'm aiming to be the first of the so-called low-code options that bucks the trend. When I'm ready to roll, I'll shoot you an email privately.
I cannot agree more with this premise. I interview and lead many developers and i have said to them so many times they probably roll their eyes when I say it that software development is not about coding. Coding is not software development. Coding is a part of it, what makes you a sw developer is your ability to determine what code to write and how to write it to solve a problem and provide a value.
no. it will just replace 60% of the entry level jobs and possibly freelance hopes for new devs looking for that first paying gig with a small business.
I feel like it has created a more problems instead solving anything. It makes customization easy for the BA person but creates complexity in the backend.... thus more bugs and unstable system. I have seen companies trying to create their own no/low code platforms and the end result is not looking great.
Going to write the answer "no" as I continue watching your opinion. I'm making more money as a full-stack supporting "low-code" than writing things from scratch which I'm perfectly capable of doing.
Dave's presentation is as useful and topical. Thank you, @Dave. Now, I agree with this point of yours, @serobification. I am quite curious about what _github pilot_ can do and cannot. For a vast number of programmers, that aspect is important, more than MS Connectors etc. So, it will be great if you follow this up with a video article on premise and applicability of the _auto-pilot_ !
I don't think you can try this platform, but there is the Pega Platform that kinda has version control and environments. I haven't tried it, but I think Camunda has better version control and environments
Dave, you are great. Thank you for sharing your knowledge and view on things. I learn a lot from your videos. The book is awesome, btw, it helped me to understand the scientific method more and to use it better at work, but not only at work))) it is kind of an ultimate tool Thanks for your hard work!
Dave, you are applying no code solution limitations to low code. Solutions like Mendix and Outsystems have functionality (version control, testing, deployment...). So, your experience is not representative of the full solution space.
No but if the platform isn't designed with extensibility and maintainability in mind it will become a difficult to manage and scale. However if it's simple see no reason citizen dev doesn't connect things together under their own context...
People say 'They've been saying this for years' or 'it wont ever happen". However we should all know that tech advances day by day and at this point anything is very much possible. They have tried to implement low code solutions many times and yes they have failed. However there is someone out there looking at those failures who is smarter than both me and you who will make a technological leap and end up figuring it out. We can say it wont happen but if you honestly think like that I would ask you to look at the technological advances already made 2 months into this year. The truth is we do not know. Anyone who says otherwise is ignorant.
I don't know. I think it is probably a different thing. Co-pilot is being described, even named, as a developer-assistant, not the thing that writes the code, but the think that helps to write the code. It is more capable than that, but again it falls into the trap of assuming that initial coding is all there is. My bet is that it doesn't do as well at debugging, or adding features to existing systems, which is much more what our job is about, and much more difficult to do well. I am 100% convinced that full AI will happen, I think that is inevitable, so one day machines will be better at all aspects of coding (and everything else) than us, lots better! I am impressed with what I have seen of things like co-pilot so far, but I think these things will need to demonstrate things like bug fixing, and adding new features and generally the ability to work incrementally. They need to be able to write code that allows them to continue making change incrementally (which quite a lot of human SW devs can't do) until then the machines won't take over. I think it's the problem solving that makes our job hard, not the typing.
I thought lowcode meant reusing exising tools and not just writing code unecessarily, not the good old "one app to rule them all, and in the darkness bind them" -lol.
You can replace “low code” with “AI/ML” and every point of this talk is still spot on.
just let him be 🤣. Hes trying to speak in a subject that he has no idea about .
Lets call it low level coding = 0 coding
High coding means a lot of coding 😎
Um no. Most serious data products are built by experienced data scientists, a discipline with practices and principles going back to the pen and paper only era. Much care is taken to organize the work and the assumption that error is present is the guiding principle.
or "blockchain"
Low-Code Node.js Builder
Easily to create node.js application and download node.js source code.
If you are looking for a tool to create a node.js application for
- Use for learning
- Use for creating custom programs.
- Use for creating programs to sell.
- Easy to use, designed to be suitable for beginners or those who are not good at programming.
* Free to use
* Inform us of the desired program. We will create an Application template for use in the future.
.
Try to Create Node.js Application
builder.impleplus.com
Web site
www.impleplus.com/en
More Functions & Futures (Document)
www.impleplus.com/document?id=54501446-e05d-4d5d-8807-ff7087659645
After falling for the "nocode/lowcode lie", that you can "building anything you can imagine without writing code", I abandoned programming and started to look into nocode tools, at first I was amazed and extremely happy that I'll finally be able to launch products without having to spend months bashing my head against the keyboard, trying to find why it doesn't work the way it should. Fast forward 3 months I'm back to coding, I have a slight disgust every time I hear about nocode/lowcode, and it's going to take A LOT for a nocode/lowcode platform to convince me to give it a try in the future. Long story short, of course it was all a lie, I couldn't "build anything you can imagine", I could barely build anything in fact. I built on 6 nocode platforms (glide, bubble, adalo, appgyver, flutterflow, backendless), and looked into many more, none of them were able to build a serious high quality, complex software product. Some of them came with a predefined user interface and didn't allow you to edit it (wtf?!), some of them straight up lacked basic functionality (seriously how tf am I supposed to "build the next airbnb" if can't even make an element invisible...), some of them were so complicated and hard to use that it would've been easier just to write code (oh, the irony) and some of them straight up didn't even work ("where was an error processing your request please try again later" yeah thanks bro) . So in conclusion, don't do the same mistakes I did, lowcode/nocode is okay if you want a small little app for an MVP or to impress your mom and you have no intention of learning to code. But if you already know how to code and/or want to build a serious software project, stay as far away from nocode as possible.
I don't think the real answer is so black and white. And a lot of these tools are still pretty immature and they are getting better. It really depends on what you are tying to build. Sometimes it is good match and sometimes it isn't. I think the issue is a perception and expectations issues, especially with management and sales. It is often sold as so easy that even business users can build their own apps, which is mostly a lie. Management also falls for the lie that you will get an x2-x3 faster app development with no real drawback. The drawbacks exist, but some that exist now, especially the good ones allow to also use real .js or java when the tool is limited. You often need real programmers or highly technical people to write the exception cases and weird interfaces or whenever real code is needed. Also all of these tools vary a lot in quality. Some are quite poor like EdorasOne and Flowable while Saleforce is much better designed and allow easy use of real code when needed.
I've been working in the IT Industry for 30+ years now (started when I was 18!). About every 4-5 years a wave of low-code/no-code solutions appears and each time they claim that programmers will be made obsolete and companies will no longer need to hire coders. There are very slick demos that seem to magically enable average business users to create data entry screens and generate reports without writing nary a line of code. This tools are scripted demos with limited application to providing solutions for the real world. As soon as the user tries to do anything off script, it is either not possible, or needs a developer who understands the underlying data (and SQL) to get the data that the user desires. The data entry screens are usually very generic and apply little validation on field input except for perhaps a static mask. The tools are very limited. After being through many cycles of these types of claims over the years, I now ignore the hype and give it little notice.
I totally agree. This is just an attempt to keep salaries down for programmers. If companies want more automation, lets start to automate off the shit programmers aren't even supposed to do: like tedious manual deployment procedures. Administrating Jira tickets..
You’re right, this AlphaCode thing reminds me of the beginnings of the 2010’s when the "Site Builders" like WIX, emerged..."is the end of webdesigners" they said...lol, from 2013 to nowadays the demand for frontend developers is greater than ever...cause tools are just tools in software process development...
Since Clipper 87 I see people falling to this idea. It's perfect until you need to evolve it or fix it. I used to try to reason with the customer before was too late, but most of the time was useless.
I was at the same point till I saw Power Platform. If we look at Power Apps, it's one environment where you can build complex app with low code, as the platform provides many out of the box features. It requires very less code, only to customise when required, but for most part it's a no code solution development environment, which is also responsive.
True but somehow me as programmer really hoping low code could help our job and be more productive
I've met plenty of academics who could code just fine, but weren't great developers. I've known business analysts who could do things with SQL just fine, but they struggled with engineering the flow of communication between critical parts of the system. Even if my IDE could write my code for me on my current project, there's more going on in the aircraft than the code inside one part of the system. There are so many different sensors, comms systems, and other things that make it difficult for me to imagine no-code or copilot style software is capable of envisioning a solution that the customer actually wants for complicated systems like aircraft, large games, exchange systems, etc.
At my last job, I ran into a wall of project managers and C level execs who were trying to push Microsoft PowerApps for more and more client facing solutions. I didn't stick around for the result, but last I heard, the client wasn't happy with the end product.
There will always be a need for software engineers for as long as computers exist in their current form.
I used to work with a mathematician and the software models he produced were a bizarre mix of the most advanced constructs in the language but with virtually zero style or understanding of memory management. Fortunately, that's not a problem when it's just a model.🤣
Nicely articulated.
The irony... the truck driver says trucks will never be fully automated. As fast as tech moves in the development arena vs autos-id say there's an equal chance both become obsolete around the same time
@@raulsanches3619
That's because truck rivers are not engineers, and personally I think they are partially right for the near future.
I think you can make self driving trucks on predictable environments like developed, maintained highways in developed countries.
The story changes when going into countryside narrow, no-lanes, muddy roads, or high crowded chaotic roads in places like third world countries.
We will wait and see anyway ....
in the future computers will disapears , it will become a virtual keyboard , VR pc .
I've been experimenting with Github Co-Pilot lately and I think it has far more potential than any of the Low-Code platforms to be useful. I don't think it's going to replace developers, but I think it will definitely help us deal with certain tedious tasks much more easily (I've found it's particularly good at helping with boilerplate, filling in unit tests and helping write documentation)
I've had the same experience with it so far.
Mhm sounds great, should probably check it out. Thanks
Do you think making it easier to write code that would otherwise be tedious it can store up trouble by helping developers write lots of code that's going to have to read many times in future?
Maybe without the co-pilot devs would have had to do something more succinct and perhaps easier to read in the first place. Although I know succinctness and ease of reading are certainly not always correlated.
@@barneylaurance1865 I'm not sure that's a Co-Pilot issue tho? At the end of the day, the existence of boilerplate is not exactly something you can lay at the door of Co-Pilot :-)
To be honest, I've seen plenty of terribly verbose code written with no ML intervention whatsoever, so I'm not sure this will change...
To clarify on the topic of tedious code, maybe I should give an example of Co-Pilot working well. I was writing some unit tests that were processing a fixture data structure reflecting the result of call to an API. After writing an assertion that some value within a map was correct following processing of the fixture when starting the next assertion it seems like Co-Pilot had processed both the test I was writing along with the fixture data and correctly suggested the next assertion I wanted. For me, that was pretty useful :-)
I think on a more general scale, Co-Pilot will be more useful for people working in dynamic languages like Python where suggestion capabilities are more limited. For people working in static languages it's going to be less useful, although not useless. It's general capability of generating suggestions based on your codebase is generally useful, I think...
The problem with AI coding is that it introduces tons of bugs and exploits, because the AI was trained on human written public GitHub code.
I am currently working on a project where we had a low code/'no code' environment. Now I have to port everything into a mixture of C++ and Python because the 'no code' version was way too slow, resource-heavy and some features would spontaneously stop working. I don't think that programming jobs will be affected that badly. Because libraries literally do the same thing as 'low code' environments. You do not have to code them yourself and we all still have our jobs.
Excellent content as always, Dave!
I used to work for a company that drank the low-code kool-aid and ended up migrating to custom code (due to extremely slow turn-around time to crank out new features, poor debugging/testing support, and unexplained performance issues) and never looked back. As for the job security threat non-sense, programmers are still needed to pick up the pieces whenever low-code systems blow up, so don't panic.
I have some experience with low code development with one of the large (largest?) low code platforms, in a legal context.
The best summary I have, I credit to a colleague: "It's great for rapid prototyping."
From my perspective, it was just like any other tool in engineering: you end up replacing one problem with another; you're shifting the complexity around, rather than fundamentally reducing it.
Biggest problems we had was around architecture and lifecycle management.
Unlike (usually) .NET or Java (or dynamically linked C/C++), when the platform needed updating, the application needed to be rebuilt - and therefore retested.
There were also architecture problems - because the app had been developed by non-programmers, they didn't have the understanding/appreciation/experience of how *GOD AWFUL* ORMs can be and the dangers of accidentally slurping vast quantities of data over the network.
There were also other issues - bugs that couldn't be diagnosed and corrected by someone who understood lower-level HTTP/HTML and Java (yes, me... And I *loathe* Java 😂)
Another MAJOR downside was the cost - the infrastructure was EXPENSIVE, *plus* we had lawyers writing software... Essentially, we ended up with untestable, poorly functioning software, written by amateurs that was extremely expensive to develop and run... And a bloody *nightmare* to maintain!
It was great for the lawyers, because they had the sense of involvement, control and progress (all the things lawyers are predisposed to), but the cost of delivery was insane - it would have been FAR cheaper to employ a couple of good/experienced devs full-time and use cheaper infrastructure (even public cloud...)
Like I said, it would be good for prototyping: let the lawyers sketch-out something that kinda does what they want, but then had it over to experienced devs to "build properly".
COBOL was developed to be the language that would cut software developers out of the loop and allow businessmen to write their own software. I would imagine the same will happen with this no code / low code fad, same as in the early 2000s when WYSIWYG editors were this huge fad and look how well that turned out.
Same with SQL. It was designed with the regular user in mind...
@@henkvanboeijen7643 it was? the syntax quickly gets complicated past simple stuff. but i guess i could see how the wordiness was meant to be a low barrier
@xybersurfer I have absolutely no problem with oracle SQL. Works fine for me, even with very complex queries and scripts.
If you want to do something complex it's going to be freaking complex no matter what language or tool you use. It's actually datastage that I have a problem with, not sql.
That archaic ETL tool is really inefficient and can get on your nerves 😂
Hi Dave, I'm a developer advocate for a low code development language and your videos have served me well in demonstrating to developers that they are not going to burst into flames and low code development is the same as traditional development from a problem solving perspective.
The advantage of the low code development tool I use is just an abstraction layer, NOT for problem solving that stays the same, but for the repetitive, dull, tasks of writing the code in a specific language itself.
For example, I develop using the same tool independently of where this code will end up, i.e. JavaScript for the client side and C# for the server side, of course I'm very ware which is which but I code the same way.
Every single method I create, their calls will be automatically logged and timed for performance.
Calling a server side method from the client side is just a simple "low code" call that gets implemented as a secured REST call to a server method with all parameter parsing so the client side can send and receive the result.
This is the power of low code.
The use case this tool covers is web development. Sufficiently broad to support the development of a banking b2c app, REST API’s or Wordle, making the problem domain far from well known.
It does support version control, debugging, logging, testing, modularity, cohesion, abstraction and information hiding, also CI/CD but only very short lived branching.
From my perspective it checks all your boxes from this episode and most from your previous videos.
So here is my hypothesis, I believe you haven't been exposed to low code generic development tools that can create applications for generic use and those applications can technically live outside of the platforms that created them.
Would you like to do this experiment privately?
No-code solutions scared me when I was earlier in my career because I thought that they would make me replaceable. I now understand that software engineering is about managing complexity and enabling change over time. Low code tools don't really introduce any new or compelling solutions to either of those problems.
All of that said: writing code isn't intrinsically valuable, it's just one approach to solving problems. If you can solve problems with less code then that's probably a win.
There will be a day when NO CODE will be a very good option. The engineers will design a AI that will ask for inputs, limits, exec.. and Write the code for you.. The AI will have the main asset form software engineers, and that is their "Problem Solving Skills." Once that happens being a software coder will be something left for a AI program that will most likely be cloud based. I am sure there will still be a need for programmers, but that need will be much less. We are at the beginning of workable AI revolution and I am sure it will be integrated in every aspect of our life. We could be 5 years away or 50 years away, but i guess is something like 15-25 years. Hints of it are already starting to show up.
Maybe. A lot of working in software is managing the stakeholder when their idea is impossible or just bad. I wonder what that looks like in an AI-powered software development world
@@tylerlwsmith it will be interesting
When I was in school in the 80s, one things was said about software development was that coding itself only accounted for about 5% of the development effort. I expect that number is even smaller today. As you point out, the actual task to solving a problem. That task is not addressed by any of the low code solutions I have seen when they arrive every few years or so.
I remember the first one was a tool where you didn't write code, you connected functional blocks together. Many were worried about that. i figured that was great, but that someone was going be needed to write the new blocks as new capabilities were required. Most low code fits this model. At this point, I see no chance that my job will be eliminated before I am ready to retire.
My problem with low code / no code is that even if it seems like it solves your problem you are then setting the client up for failure in the future. Most of these solutions are small companies that might not last long, and usually they want to host the solution in someway. Plus by the time you bump into the edges of the system the client is already deeply invested in it. So it would have to provide such great value in the short term that it wouldn't be all cancelled out with the costs of migrating away from it after a certain point.
Hey, Matthew Harris, We are also 20 years old small company. Have also created many successful story. Would like to share our details privately. Let us know when can we connect.
Great talk and communication too. And an open-mindedness I would never have.
You are pointing the real great problem of no-code: no-code means no code lifecycle management. And that's a source of disaster. I always find my team importing stuff from Production to realign things in Development, or redeveloping things after being released to adjust small bits here and there.
Also, the no mistakes allowed philosophy really bugges me. If I develop an unnecessary component and release it by mistake, some no-code tools under certain conditions will never allow me to remove it.
During my work days I find myself saying "Were it code, this wouldn't happen" too often.
I'm in charge if product management for a data driven business application used nationwide with complex role based functionality. I couldn't be where I am without low code. I also couldn't be here without complementary custom development.
These two things are not mutually exclusive. They are AND, not OR.
Excellent talk. I really enjoyed a) the fact that the mid roll advert was for a "no code solution" b) the use of examples from your own experience (sometimes you can be very theoretical and I find it helps to illuminate the subject you're talking about) and c) this being a dive into a bit of a side subject, something we come across but don't necessarily have the time to dig into personally.
Good work
Great video that agreed with my experience. Excel is a great low code tool for business people. It is really powerful. I had the misfortune to work on an application written in Excel and VBA. No testing no version control and global variable hell. Not only that the developers working on this needed file locking and the ability to perform timezone conversion. This is where excel started to unravel. So the company wrote excel hacks to achieve this and wondered why things went haywire when their custom file system locking was failing. Sometimes you move away from the well defined area low code is good at and you end up having to reinvent the wheel. The discussions about the performance were also challenging. The developers expected to have infinite file system performance and infinite network bandwidth. When the network was saturated with dir data their application state ended up being corrupted due to no checkpoints or property error handling. Rubber bands and sticky tape holding it together.
The levels of complexity required come from the business problems not the coding tool.
So difficult to get this through to those in leadership.
I prefer to look at low-code for what it's good for: a way to quickly develop a working prototype and modify it as we work out the problem domain. Sometimes the edge cases haven't all been worked out, sometimes the problem isn't obvious, and only when you put in operation do you see where the hiccups in the processes are. This would be fairly common in small businesses and operations, I think.
Agreed - it makes a great way to prototype
No code/Low code has already taken over. If you are a java developer, you are highly likely to use the Spring Framework, which has taken over lots of boiler plate aspects and you are just hooking up your custom code. This means it take a fewer developer to code up a java project than it used to be in the pre-Spring Framework days. Coding will not be lost, but the problem domain will shift to a higher level. Probably, machine learning.
Great video. I once saw a presenter at a conference expressing pride that his solution looks like the wiring diagram for the space shuttle. That's a bug, not a feature and I pity the person who has to maintain that 'code'.
Another awesome shirt! Come for the programming ideas, stay for the t-shirts, man!
I've heard this one before. Back in the early/mid 1990's we had CASE tools that were going to revolutionize software development. It was a bunch of vapor that just went "poof!"
I don't think low code/no code solutions could ever truly replace programming jobs. After all, programming at its core is nothing more but a way to formally specify our requirements on behavior and a programmer's job is translating highly-abstract human-level wishes and desires into highly formal computer-level specification. Until we have human-level AI that can understand human intention and translate it into machine code, programmers will be needed to do that translation.
Higher-level languages can certainly be useful since they allow us to combine "pre-packaged" formalizations and not do all the nitty-gritty details each time, but at the end of the day, the rubber has to meet the road somewhere. It seems to me that low code/no code might certainly be useful if our use case is so common that those "pre-packged" formalizations are feasible to define on a very high abstraction level, but I think that ultimatetly they'll likely end up as just another tool that can make programmer's life easier. There are simply too many problems to be solved for the super-high-level abstractions to be flexible enough--as evidenced by what you've mentioned in your video about the trade-off between the system's flexibility and the solution looking more and more like code.
That AI will come, but by then, we'll have very different problems
@@ric7044 I agree on both points--once human-level AI comes, programming being obsolete will be the last thing on our mind!
Wordpress, wix, squarespace etc didn't replaced web developer jobs, instead tools like wordpress by allowing everyone to have a website, indirectly promoted new markets for developers to develop custom themes, plugins etc.
A key drawback of general purpose low-code solutions is that while they can successfully abstract away the complexity of the general problem, they cannot abstract away the complexity of the specific problems that an organisation may want to solve. An organisation of any significant size almost certainly has more organisation specific complexity than general complexity.
A hybrid model of code and low-code can be quite successful in my experience. In such a model, software developers build out functions/services/interfaces that abstract general problems (ie. talking to a database, sending an email) to higher level organisation specific concepts (ie. notifying all staff in a division) using good old fashioned software development and code. Non-developers can then build low-code apps/content using these systems which are framed in organisation specific language and concepts.
As a tester, welcome developers to the "automated" discussion. We've been engaged in this for a long time and I can't see automated development being a thing either. You could replace "low code/no code" with test automation in this video quite easily, as well as AI/ML as others have mentioned. Even down to the part of grandiose tools marketed by vendors etc. We've been here before and for quite a while!
The philosophy of No Code is fundamentally one of empowerment. It is enabling people without coding skills to be creative in the same way developers are. Such systems have been around for some time, spreadsheets being an example of pervasive tools. There is of course an overlap; even Excel has expanded from allowing expressions to full on languages in cells. But the core philosophy is to empower people disenfranchised from the act of creation through because of barrier of technology.
That’s a little bit like saying that copy-pasting clip art is empowering to people who don’t know how to paint. It is in a sense, but you’re ultimately still very limited.
@@davew2040xLuckily my case isn't for replacing all application development with no code tools. It is the case however that the current microservice philosophy and domain driven development actually promotes domain binding rather than making software more general. No Code or low code is really about domain decoupling, which improves quality and development speed. Yes; it is constraining, so I don't promote these solutions as something that will replace programming.
Brilliant take.
Why are we so obsessed with replacing the Software Developers? ...using software.
I've been hearing this for almost 30 years now. I'm not too worried.
Outsystems as a low code development platforms enables developers to build enterprise level full stack applications. It provides end to end development features including Devops, Production and Quality assurance. We can now build complex applications within very short time span.
This was experience with a machine vision ide by cognex called cognex designer. It was sold as making it easier to write machine vision systems so you don’t need software developers. It had a flow chart style programming interface. It was great for simple throw away experiments and demos but when it came to real applications managing a spider web of connections between different functions in the graphical interface became overwhelming.
Of course it allowed you to write custom code in c# but it didn’t let you write classes, not in the ide you could make these in visual studio but you had to close and reopen cognex designer every time you recompiled.
It also packaged all the files up in a zip file they called a cdp. I did use git but it was difficult to understand what change you made caused the issue that you needed to role back for.
In the end software developer wrote all the software and the non developers didn’t want to touch it.
Management didn’t really seem to understand this.
Thanks for your insights on this topic, big fan! would like to highlight that more sophisticated low code platforms offer code version control capabilities through GIT such as node red, and also automated testing and cli for enabling continuous delivery such as powerapps. however, your comment related to modularity and separation of concerns ponders me how to approach it, perhaps a next step to tackle in the low code systems
Exactly. Low code is here to stay, and the current problems will continue to be tackled. Thinking otherwise is just clinging to the past
This is the most balanced opinion on Low Code that I've seen. It has its uses I'm sure, but I think it's currently being sold to people who frankly don't understand the complexity behind most software, and how that complexity can grow over time. I'm also suspicious of the fact that most of the low-code content on youtube being from salespeople basically, there seems to be no in-depth discussions of the actual pros and cons.
We do not think it will kill jobs - if anything, it will amplify it. As of today, you can only create faster prototypes with nocode, but you cannot completely replace code. We build prototypes all the time.
Wonderful, I did not have the words to express my opinion, this video took care of it. Nailed it.
There will always be programmer jobs in the classic sense. Maybe less of them, but they will be around. *Someone* has to build these tools in the first place for one, and then there will be things those tools just cant get quite right automatically - especially if on time execution requirements are involved (ie displaying frames on any screen)
I've seen very successful projects with robotics process automation (RPA) tools, these also run under the label low code. In most organizations there is much more IT demand than the available IT ressources or IT budget. After prioritization most of the smaller and not so critcal requirements are postponed to the next sprint/budget period/year (multiple times). Some of those day to day problems (mainly copying data from one user interface to another user interface or inserting data from an excel source) could be easily solved by the "business programmers". If you use the right tool, then you also have separation of Dev/Test/Prodution stages with proper tools to transport from one stage to the other. The Business Programmers tried some more complex integrations scenarios but then realized that this probably a job for the IT guys. Overall the organization was able to implement more requirements than before. If programmers feel threatened by these tools, they are probably working on too trivial problems and should step up.
good points again. i've experienced the testing in production issue and the bad documentation. it's interesting that i never considered the lack of control over the configuration of such systems. i'll be checking out your new book, i like the reviews and can always use some wisdom (already ordered a copy)
That's the experience I got from Scratch coding. Assembly of code from blocks seems good until you find all the limitations. However, Deluge (Zoho) is the opposite - highly productive code for business apps.
I used some of these tools around 10 years ago. Even with a lot of support from the companies making these tools they were incredibly painful.
The thing is people who execute low code or no code platform are mostly( but not entirely) developers. They who use completely understand what the video is trying to make a point and kinda know the limitations of the low code idea. The people saying this gonna replace the traditional coding is the one who never into coding seriously
I have been using Low-Code OutSystems Platform for about 10 years now and although it is based on visual programming and helps abstracts a lot of complexity, we still need to have a developer mindset.
Proprietary database: typically, we have had to buy separate licenses for an isolated test environment. Then find a way to replicate the changes without retyping them.. The licenses can be expensive, and often forced sharing a single test environment for budget reasons. There are "partner" programs that vendors use to help, but these come with their own constraints (cost or minimal resale volume requirement). In one case, the minimal license cost was in the 6 figures and nobody was willing to pay, so warn, ship and let the customer tests it. This is part of Open Source popularity..
Dave are you willing to share the names of these low code products you use ?
Really like your Flynn's Arcade shirt... Excellent talk! What concerns me is that I've seen lost knowledge each time we abstract another level - like robbing those who program or work with tech the experience (maybe pain) where you are forced to learn something you might not have otherwise come to learn and is useful for your development. I've seen this in IT operations as well. Just a thought... but thanks very much nevertheless!
More people need to be making videos about this. There is way too much hype out there and too few videos of people critical about no/low-code
Great video Dave. Could you talk about this use of the word "AI" in our industry? It seems like real AI was promised decades ago and then suddenly people started saying "machine learning" which has now turned into "AI". I feel like many people don't understand that it's not really "AI".
It's like "Organic", or "Metaverse". Words with so much marketing value, that they are overused to the point of losing their entire meaning
Thanks for the suggestion. I have been thinking about something on this topic for a while, the GitHub co-pilot may push me to do something 😎
Great summary of the pitfalls coming with "simple" solutions, I 100% agree with that (and had some very similar discussion with some low code guys)
I've been working with a startup for 2 years now. We had our ups and downs but things were going pretty well until recently when he's decided to switch our code base with use PHP, Symfony and mysql to no code/low code. I've told him that it's quite risky what he's trying to do but he didn't want to listen so i've agreed but the more i use the tool ( bubble ) the harder i find to go from a programmer mindset to no code and so i've called him and told him that it would be hard for me with the deadline they are asking when i'm pretty bad with these types of things and since they're still in early stage (startup), i don't want to waste their time (a.k.a money) and i've told him to find someone that is more comfortable with bubble. He felt disappointed somehow. What did i do wrong! (i'm 23 by the way)
sirven para cosas sencillas, ya cuando necesitas validaciones complejas, procesos pesados de datos, ademas de reutilizacion de codigo (olvidalo)
I have the displasure of working with a low code platform for developing multiplatform applications at the moment. It's terrible. Nothing works exactly as you expect it to, there are always differences. Most things are hidden behind layers of abstraction which make it more, not less, difficult to work with, simply because it's so different. Half the time I ignore the low-code options and write everything from scratch anyway. I wouldn't recommend starting your career in this field.
Live configuration changes: that is so true. Facebook network engineers would probably agree.. In all systems there is a need for auditing changes (requires logging) and rollback (requires versioning).
Everything old is new again. We've been trying to do this since at least the 80s (and maybe earlier). In my view, things like Excel point the way: low-code solutions just aren't going to look like traditional code at all.
when you gave the example of square space - i could visualize what you’re discussing.
No. But it will also continue to trivialize the task of app making(and programming, in general). People already think that it's super easy and should only take a day to create an enterprise-level app---built, scaled, and secured.
I've been doing low code, no code for 24 years with C++ Builder which is one of the best rad told in existence.
Low code stays limited. It kills maybe the jobs of low salary script kiddies, but the real work is finding a solution to a problem and for every complex problem low code won't be enough.
Super interesting topic and video! 👌
I like this "best code is the one that you don't write" idea so people can focus on the things that matter.
I agree with pretty much every point made. Here are a few related personal opinions -
Sometimes the most practical approach to testing something is to just test it in production, because the functionality being produced is critically needed and the time it would take to produce it effectively otherwise is prohibitive.
Biological neuroscience shows fairly conclusively that human cognition is the result of a mechanistic process, so AI cognition can and probably will eventually catch up with and even surpass human cognition. At that point, AI programmers might replace human programmers. But I don't think low code/no code systems ever will, for exactly the reasons presented.
I think most people think low/no code solutions will replace programmers on a large scale believe that most significantly different problem domains that are possible or likely to ever exist have been or will someday be thoroughly explored enough to be condensed into no/low code solutions. I sort of think that's a ridiculous idea, because even if all significant problem domains were so thoroughly explored (which by itself seems ridiculous to me) drilling down into the level of "configuration" details that would be required in many, many specific real world instances would more-or-less amount to programming.
Lowcode tools require tons of code. .SAP is selling nocode tools on one hand but is also making development of custom apps extremely complex
First, let me say I love your t-shirts. Yet again, this is a great one.
This isn't a comment on this specific video, rather a comment on the ideas you promote in general.
My problem isn't any one specific idea, it's that most of the things you promote depend on doing them perfectly 100% of the time, and more importantly, building on other things also being done perfectly. Ironically, you always talk about reducing coupling, but the very ideas you promote are tightly coupled. What do I mean by this?
* In order to do CD you need to do CI, have reliable unit tests, have high assurance of correct code, use trunk-based development, do pair programming, do tdd, etc...
* In order to do CI you need to have reliable unit tests (I won't say coverage, because we both know that's a useless benchmark)
* In order to do CI you need to be able to constant commits and use techniques like feature flags (which are not useful for many kinds of changes, such as database changes that break the alternate paths)
* In order to have high assurance of correct code you need to use pair programming (because you can no longer do pull requests due to trunk-based development)
* In order to have reliable unit tests, you need to do TDD (otherwise you have tons of issues with useless tests that test implementation)
* In order to do TDD you need to write it from scratch as testable (yes, there are techniques to improve code and add tests to legacy code, but that's not really TDD and it takes a very long to for those tests to be useful much less reliable at indicating broken code).
And so on, and so on...
This seems like there's a huge coupling between all these techniques, take one out and the entire process fails. Which makes it much much harder to incrementally achieve CD, especially if you have a lot of legacy code (like most organizations) that doesn't use those techniques and isn't very testable.
My experience, and I have no hard data to support his, is that doing TDD adds about 15-30% more effort up front, but reduces rework by up to 90% on the back end. This is great. But trying to add unit tests after the fact (again, in my experience with no data) is that it can take 50-250% of the original effort for a fraction of the tdd based benefit (unless you end up essentially rewriting the code in a tdd way as part of the refactoring, then you get the full benefit but still at huge cost (closer to that 250% when all is said and done)).
I'm not disagreeing that everything you promote, when used together, results in significantly better software. I'm simply wondering if it's truly practical to expect this perfection, and if you're not perfect, everything falls apart anyways. (all too often when someone comments about how this process or another fails it's "You weren't doing it right", which implies not doing it perfectly leads to failure)
Sure, perfect is the enemy of good and all that, but why is tight coupling bad for software, but good for software methodology?
250% more effort is a hard sell to management. At that point, you might as well throw the code away and rewrite it from scratch, but that's also a very hard sell, so you end up with only lukewarm support for your entire process, and if you don't get full buy-in what's the point?
Sure, and retrofitting this stuff is more difficult that starting from scratch, but while I agree with the general aim of your comments, I disagree with some of your conclusions. Sure, retro-fitting TDD to an existing codebase is more difficult, so organise things so that new work is possible with TDD, but don't retro-fit to code that you aren't changing.
"CI you need to have reliable unit tests" well yes, but if you have 1 reliable test that stops you making a common mistake, that's better than none.
Pair programming is a choice, it is not difficult to adopt if people want to do it, so start discussing the reasons why the team might like to try it.
I agree that some of this stuff is difficult to change, but it is not impossible, in fact I make a living help companies and teams do that, we almost never get to start from a blank-sheet.
Step 1 in solving any problem is identifying that there is a problem, step 2 is coming up with something that may address the problem 3 is trying it out to see if you can make it work.
Here I certainly try and help people with steps 1 & 2, the trouble with step 3 is that it is a bit more contextual, but there are plenty of videos here that try to tackle step 3. Checkout my stuff on refactoring, or acceptance testing.
The only bit that I disagree with is the assumption behind "250% more effort is hard to sell" - So don't! Don't structure this as "250% more effort" find small changes that you can make that don't really add more effort, they just change where you apply the effort. Make the code that you are working on now, today, a little better. Write new code with tests, and do the work to isolate that new work from the big-balls-of-mud elsewhere so that you can. I think that you get to, what I concede can look like some fantasy Nirvana, by many small, practical steps, not by huge stop-the-world-efforts.
@@ContinuousDelivery I don't disagree that you can improve legacy code, I disagree that you can ultimately achieve the nirvana you describe with most legacy code bases, and this leads managers to think "Just add unit testing and all our problems go away, we don't need a testing department, etc.."
My other main argument is that CD as you describe it is not very easy to achieve, and may be impossible with many legacy code bases.
You have made it very clear that you don't think it's possible to do CI without trunk-based development, and you have also made it clear that the only way you can do code reviews effectively with trunk-based development is pair programming. I can't place it, but I think you may have even said that the pull request methodology was harmful, because it prevented CI.
And this is where i get into the idea that your methodologies are incredibly brittle and coupled, and prone to failure. If not done perfectly to achieve CD. Many of those practices, sure, can be used independently, and they can improve the code. I just don't see how most organizations can achieve your nirvana without starting over.
I know it may sound like i'm attacking your positions. I am not. I agree that what you describe can work. I just want you to consider how realistic and effective it is to do in most organizations and most code bases.
@@erikf790 Such a codebase is never going to be pretty, but you can usually make it workable. Most organisations that we think of as good at CD started from a legacy codebase! Amazon used to be a 3 layer PHP & relational database application! Software is infinitely malleable, so the question isn't really "is it possible", its always possible, a better question is "is it worth the effort" and that depends on the system. If you are about to retire it, then "no!". If this is the core of your business, and your business is uncompetitive, then "yes!" and there are lots of shades of grey in between. I know it's a nice thesis, but I don't buy the idea that these ideas are coupled. Yes they are coupled at the limit, but if you have no tests and you add 1 then it's an improvement. It looks coupled when you see a highly optimised, effective version, but the journey is one of lots of independent, parallel, steps.
@@ContinuousDelivery Amazon is probably the worst example you can give. They have almost certainly rewritten their entire code base (perhaps several times) over the years. They also have nearly limitless money to throw at it if they want to.
But I've said my peace...
Great observations, Dave. I'm trying to help enterprises understand lcnc and you raise many valid points. The bottom line is that today low code = low engineering so think about the use case and environmental factors.
Also a big need for lcnc development is governance to manage tech debt, duplication and data integrity. The route to live needs better QA and operations management too.
All things that business users don't ask about and most lcnc vendors address.
I'm working with some standards bodies to try and deal with this..are you doing work on this too?
Hey 6502Nerd, We can join hands, let us know when can we connect privately.
Will be happy to show our rapid development tool.
While most of lowcode platforms struggle from all those problems with no version control, tests etc., some of their authors already noticed that. E.g. Microsoft allows their "power platform"
solutions to be kept in json file (which can be versioned) and they can be deployed from CD pipeline. This way, I think it's possible to have also a development environment. Although since most of them are used for integration, it's still hard to test them. While you can trigger logic apps/powerautomate manually, I think it's still hard to truly test the trigger (but if you integrate programmatically, e.g. by webhooks, this is true also).
Of course, such tools with all that development ecosystem (version control, pipeline, automated tests) will still be too complex for someone not specializing in them, so I predict that "low-code is a new code" and some of us will use them as we currently use any programming language. Just text files will be replaced with diagrams (which I like BTW)
The big benefit from them however might be lowering the threshold for beginner. It could be possible that simple applications will be created by business, users etc. and if the application becomes bigger and more valuable, it's creators might start solving the scale issues by learning development tools. Also such an app could be taken over by professional dev and they might gradually improve the development process or the app itself without all the hassle we now have when working with low-quality code
I am pleased, and not surprised, that some low-code systems are trying to address some of these problems. I am sure that we will make progress on this at some point, but people have been trying this for a very long time and it hasn't really worked, except in very specific, very constrained, circumstance (like spreadsheets) and even they suffer the same problems when people inadvertently cross the complexity boundary.
I noticed you never used a no/low code system that was normally designed. They have all elements you mentioned as a version control and a testing site. I could say that an embedded version control is a key feature of any real no code system.
In which case my argument doesn't apply to those types of lo-code systems, but I still think that they are the minority, at least in terms of popularity.
@@ContinuousDelivery Certainly, lo-code system still didn't get much popularity, but I believe that the situation will change with AI improvements.
So this is similar to flutter ? Like Google made it to make one app for both Android and iOS but it was rarely use in scaled business
The hateful thing is the vendor snakeoil sales, and then selling the promise to "management" in enterprises who know no better. So many companies trying to go through a digital transformation now, there are rich pickings out there....
As an SDET who worked with the so called low code solutions I can attest that they require more coding/tweaking in order to work than a proper scratch built test harness.
One of the systems I work with was touted as low code. It ended up needing tens of thousands of lines of Javascript (cient and server side) and APIs (C#).
Well, you could count yourself as lucky -- a decade and a half ago it could have been tens of 1000s of lines of XML, XSLT and XQuery -- I have worked on such a "low-code" system and at the time would have been happy to swap it for a Javascript and JSON based system.
@@djl3009 I'll drop a guess and fly away... mmm... Oracle OSB?
Does this all apply to BPM and Salesforce development? Some of the BPM tools I have seen have no automated testing, no source control and a dynamic, but inefficiently created database.
I don't have any experience of either, but from what I understand from other people, then yes it applies.
Trust formal specification systems like TLA+ in combination with code generators more than "Low Code/No Code" solutioning like Github autopilot.
Additionally, this quote from the 1960s (YT - 9min marker of Auto Worker Hated His Job & Felt Like A Robot. Doesn't See Automation Coming) certainly comes to mind when it comes to automation in the workplace:
There are two different kinds of futures - one where everyone will be retrained and will be able to bring their new abilities to the new products and needs; the other which we all fear and must avoid (sic) is that we go on with our program of making more and more things automatically and training scientists and mathematicians who live in a separate world from the mass of the people. And the mass of the people are freed from work but will become less and less interested in the life that they have to live.
There’s a saying in journalism that if the title is a question the answer is invariably no.
Yes, "Betteridge's law of headlines", now I am very tempted to come up with a video that breaks that law 👺
I wanted to thank you earlier for this great video, but had to figure out how to trigger the UA-cam API first. Using the plain comment function seems suddenly too ‘low’ 😅
Interesting. What are your thoughts on AI / Neural Networks writing code?
There's been chatter about some of them working on confined problems relatively well.
I imagine it could be helpful in a few years, e.g. by describing a problem and the computer creates a library that adheres to your defined interfaces to tackle it for you.
Of course, and very obviously, the AI may have drawbacks, such as not accounting for every edge case.
But in these cases, just like a real developer, you'd adjust your tests (as part of the interface) and the AI will adapt the library to fulfill the new requirements.
I think you have to have a look to pega prpc
I'm on board with your assessment of *existing* low-code solutions. However, while it is difficult _not_ to make said assessment of such systems based on what you've encountered, it's analogous to making assumptions about a group of people based on the only ones you've encountered. To be clear, the low-code concept is not less powerful, it's the current implementations, presumably by people who are attempting to solve the wrong problem.
I think that’s what I said 😉
@@ContinuousDelivery Then, I sincerely apologize for missing it :^) In any case, I'm aiming to be the first of the so-called low-code options that bucks the trend. When I'm ready to roll, I'll shoot you an email privately.
I cannot agree more with this premise. I interview and lead many developers and i have said to them so many times they probably roll their eyes when I say it that software development is not about coding. Coding is not software development. Coding is a part of it, what makes you a sw developer is your ability to determine what code to write and how to write it to solve a problem and provide a value.
The more afraid of programming we get the slower, more bloated and less reliable our industry becomes.
I like that!
no. it will just replace 60% of the entry level jobs and possibly freelance hopes for new devs looking for that first paying gig with a small business.
I feel like I should be telling you to lie down on the couch and tell me about how the low code tool hurt you.
I feel like it has created a more problems instead solving anything. It makes customization easy for the BA person but creates complexity in the backend.... thus more bugs and unstable system.
I have seen companies trying to create their own no/low code platforms and the end result is not looking great.
Going to write the answer "no" as I continue watching your opinion. I'm making more money as a full-stack supporting "low-code" than writing things from scratch which I'm perfectly capable of doing.
Love the shirt!
Low /No programmers can continue dreaming about low / no code replacing programming jobs.
Dunno. Low Code only leads to software that is harder to test. Currently this is the case with our ESB...
Dave, from the title I'd have expected that the majority of that episode's time is spend on Github's co-pilot or such AI solutions.
Dave's presentation is as useful and topical. Thank you, @Dave.
Now, I agree with this point of yours, @serobification. I am quite curious about what _github pilot_ can do and cannot. For a vast number of programmers, that aspect is important, more than MS Connectors etc. So, it will be great if you follow this up with a video article on premise and applicability of the _auto-pilot_ !
I don't think you can try this platform, but there is the Pega Platform that kinda has version control and environments.
I haven't tried it, but I think Camunda has better version control and environments
I worked for a company that used pega , spent £1.5m on it hundreds of offshore developers then throw it out.
Dave, you are great. Thank you for sharing your knowledge and view on things. I learn a lot from your videos.
The book is awesome, btw, it helped me to understand the scientific method more and to use it better at work, but not only at work))) it is kind of an ultimate tool
Thanks for your hard work!
Thank you! Would you mind adding a book review to Amazon please? 😁
Node Red has projects which are git repos
Dave, you are applying no code solution limitations to low code. Solutions like Mendix and Outsystems have functionality (version control, testing, deployment...). So, your experience is not representative of the full solution space.
No but if the platform isn't designed with extensibility and maintainability in mind it will become a difficult to manage and scale. However if it's simple see no reason citizen dev doesn't connect things together under their own context...
That Squarespace roast though. 15:03
Hey! I have that shirt! It’s my favorite!
People say 'They've been saying this for years' or 'it wont ever happen". However we should all know that tech advances day by day and at this point anything is very much possible. They have tried to implement low code solutions many times and yes they have failed. However there is someone out there looking at those failures who is smarter than both me and you who will make a technological leap and end up figuring it out. We can say it wont happen but if you honestly think like that I would ask you to look at the technological advances already made 2 months into this year. The truth is we do not know. Anyone who says otherwise is ignorant.
Question: is co-pilot low code? Or is it just a evolution in a type of inteli-sense for development.
I don't know. I think it is probably a different thing.
Co-pilot is being described, even named, as a developer-assistant, not the thing that writes the code, but the think that helps to write the code. It is more capable than that, but again it falls into the trap of assuming that initial coding is all there is.
My bet is that it doesn't do as well at debugging, or adding features to existing systems, which is much more what our job is about, and much more difficult to do well.
I am 100% convinced that full AI will happen, I think that is inevitable, so one day machines will be better at all aspects of coding (and everything else) than us, lots better! I am impressed with what I have seen of things like co-pilot so far, but I think these things will need to demonstrate things like bug fixing, and adding new features and generally the ability to work incrementally. They need to be able to write code that allows them to continue making change incrementally (which quite a lot of human SW devs can't do) until then the machines won't take over. I think it's the problem solving that makes our job hard, not the typing.
Ever time he said low code I kept thinking of the Spanish word loco. Maybe there is a connection.
If you compare software development to Lego, Low-code is Duplo. It’s more of the same but with larger bricks.
...and its harder to make spaceships 😎
anybody remember rational unified process?
if by some miracle, people created low code tools using low code tools, it must literally be low low code
"Everything worked Except it didn't" should be on your next t-shirt.
I thought lowcode meant reusing exising tools and not just writing code unecessarily, not the good old "one app to rule them all, and in the darkness bind them" -lol.