Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Businesses IT

Will Low-Code and No-Code Platforms Revolutionize Programming? (forbes.com) 136

Posted by EditorDavid from the pondering-platforms dept.
In a new article in Forbes, a Business Technology professor at the Villanova School of Business argues that the way we build software applications is changing: If you're living in the 21st century you turn to your cloud provider for help where many of the most powerful technologies are now offered as-a-service. When your requirements cannot be completely fulfilled from cloud offerings, you build something. But what does "building" mean? What does "programming" mean...? You can program from scratch. You can go to Github (where you can find code of all flavors). Or you can — if you're a little lazier — turn to low-code or no-code programming platforms to develop your applications.

All of this falls under the umbrella of what, the Gartner Group defines as the "democratization of expertise":

"Democratization is focused on providing people with access to technical expertise (for example, ML, application development) or business domain expertise (for example, sales process, economic analysis) via a radically simplified experience and without requiring extensive and costly training...."

[T]he new repositories, platforms and tools are enabling a whole new set of what we used to call "programming." As Satya Nadella said, "Every business will become a software business, build applications, use advanced analytics and provide SAAS services," and as Sajjad Daya says so well in Hackernoon, "Coding takes too long for it to be both profitable and competitively priced. That's not the case with no-code platforms, though. The platforms do the complicated programming automatically, slashing development time..."

The technology democracy has forever changed corporate strategy. And what does this mean? It means that the technical team scales on cue. But "technical" means competencies around Github, low-code/no-code platforms and especially business domains... [A]ll of this levels the technology playing field among companies — so long as they understand the skills and competencies they need.
This discussion has been archived. No new comments can be posted.

Will Low-Code and No-Code Platforms Revolutionize Programming? More

Will Low-Code and No-Code Platforms Revolutionize Programming?

Comments Filter:

  • No (Score:5, Insightful)

    by chthon ( 580889 ) on Sunday February 23, 2020 @03:46AM (#59756204) Journal

    Because building something has nothing to do with code, but with understanding the application domain.

    You might be able to build something that goes 80% of the way, but if you don't understand the application domain, you will never be able to create a process that has a minimum of failures.

    Understand the word "process" here: running your stack every day, and not having every day failures (and thus loss of time and money) because the use cases that get supplied to your system are not completely mapped, or change in the course of time.

    But then you should not only be able to understand the application domain, but also to map it to the correct software structures.

    What everybody always misses is that you need someone who is smarter than the business users: a programmer must understand the business user, what he is doing, his application domain, and be able to map it to software.

    And don't get me started on non-functional requirements like number of users that should be able to work in parallel, response time of the software and security administration.

    • Why is a process with a minimum of failures the desired outcome? Building something for the application domain means meeting business goals, not writing perfect code. More perfect code takes longer and costs more. The perfect is the enemy of the good enough.

      • Except we're not talking perfect vs good here, we're taking good vs crappy.

      • In the vast majority of cases, frequent failures - wrong data every month, is far more expensive than a one-time investment in coding it correctly. The hours spent "tweaking" the output from Excel macros in this country, when the user happens to notice that they are wrong, are staggering.

        Right now at work one item on my TODO list is some data ingestion written by non-programmers and then they spend AN HOUR A DAY fixing up the output so that it can be used by the business processes which require it. As a m

        • Re: (Score:3)

          by gweihir ( 88907 )

          Indeed. Because of amplification effects, bad software is exceptionally more expensive than good software. On the other hand, writing good software is hard and not many people can do it, so while bad software is exceptionally expensive, its up-front const is a lot lower than that of good software.

          Fortunately, the cost of bad software is going to raise even more, as criminal enterprises have realized they can make good money via ransomware. Hence there is a chance this amateur crap-show is going to end event

          • This. I wish I could figure out how to make nontechnical managers understand this.

            • Non-technical managers tend understand columns of numbers with dollar signs.

              Do you and and I, as technical people, know how to write in that format? To even think effectively in those terms? That's the language of business, so it behooves us to learn it.

              • A senior developer almost by definition understands the business, and has or at least should have a large stake in its ongoing health and profitability. OF COURSE we think in those terms, and we explain in those terms, and we get ignored. Meaning lots and lots fewer of those dollar signs. For everyone, including our managers, and including us.

                • I think the difference is what incentive structure are you using vs the non-technical managers.

                  Especially as developers we feel the pain for longer term projects / tasks and we try to avoid technical debt where possible but you have to remember the CEO's goal is to just make the next quarter look good or he may not be in charge for the following quarter, that mindset permeates all the way down.

                  The technical debt is practically invisible to the non-techs so is not a deterrent to them.

                  • Different perspective: I think that the technical debt absolutely IS visible, in the form of quality problems, scalability issues, early life failures, difficulty in adding new functionality that should be much simpler than it actually turns out to be, turnover of development staff, high support costs, and the like. If good software is expensive, poor software is, generally, MUCH more so. However, management does not perceive the technical debt, caused by their own insistence on not spending enough to pa

      • Why is a process with a minimum of failures the desired outcome? Building something for the application domain means meeting business goals, not writing perfect code. More perfect code takes longer and costs more. The perfect is the enemy of the good enough.

        I work on systems that deal with public safety (as in my code doesn't work and the police/firefighters/etc don't show up). The Boeing Co has been in the news a lot about software errors crashing planes. How about software for the ISS? I could go on with the list, but there are many cases where a "minimum of failures" is definitely the desired outcome.

        I didn't read the article, but the summary made me laugh. Maybe it's possible on simple stuff like accounting and other simple systems, but there are entire

        • To be fair, it wasn't software errors that crashed the planes, it was a single point of mechanical failure, when there should have been redundant systems.
    • The nocode/lowcode and even RPA platforms run often distributed or separated from the core platforms. They run as automations as a layer on top or in-between. These are automations that can easily be built by non programmers with some training. There is no 'stack' involved. They are functional layers that are customised to business specific processes. It removes the need to have specialised developers create customised code on top of existing (ERP and other) systems to finetune to a specific business need.

      • Re: No (Score:4, Insightful)

        by ArmoredDragon ( 3450605 ) on Sunday February 23, 2020 @08:35AM (#59756534)

        Personally, I'm thoroughly unimpressed with most RPA solutions. Essentially they require you to build a flowchart, which is your actual "code". Prototyping is much more difficult, as is deciding. Object oriented programming obviated that crap a long time ago. Personally, I've found it far easier and less time consuming to script that stuff using powershell. Although, when I do so, my powershell code more resembles c# as I tend to avoid cmdlets like the plague, opting instead to call .net directly for just about everything.

        • Although, when I do so, my powershell code more resembles c# as I tend to avoid cmdlets like the plague, opting instead to call .net directly for just about everything.

          Why avoid them? They work fine for their intended purposes. It's only when you're dealing with unusual or large data that you need to work around them. Most of the time it's not the cmdlets, it's the way the data moves through the pipeline that bogs you down.

      • Re: (Score:2)

        by gweihir ( 88907 )

        You are mistaken about what a good programmer does. Mastering a language and a "stack" is a minor part of that. So, no, non-programmers cannot simply start to write good applications because the tool has gotten easier to use. They still can only hammer in that nail, anything more complicated they are bound to mess up.

    • Re:No (Score:4, Informative)

      by arglebargle_xiv ( 2212710 ) on Sunday February 23, 2020 @05:52AM (#59756332)

      Yup, definitely. The program you're thinking of is called, appropriately enough, The Last One [wikipedia.org], because it will make the task of programming obsolete. After you buy The Last One, you'll never need to buy another program.

      The Last One was released in 1981, and it's obviously been completely successful, just like every other program since then that promises to do the same thing

      • Oh cool thanks for the link. I toyed with that thing back when I was a kid. Went back to BBC AppleSoft Basic in about 1 hour.

      • Re: (Score:2)

        by gweihir ( 88907 )

        Hahahahah, nice reference. Also shows that people continue to be clueless and expect the next big thing to solve all of their problems, against overwhelming historical evidence that this never happens.

        • Re: (Score:2)

          by rnturn ( 11092 )

          ``...people continue to be clueless and expect the next big thing to solve all of their problems ...''

          I..e, business school faculty and Forbes subscribers.

    • Yes no code "programming" is going to change things. as stated the question initially seems dumb or superficial and invites the answer no. To call no-code platforms programming is an oxymoron. Is pushing the button on an automatic elevator "electromechanical engineering" ? No-code is not programming either. But the right question is "is programming going to be a relic." We still need ditch diggers to lay telephone cable, and we'll still need programmers but they won't be the main show.

      So the right answe

      • Re: (Score:2)

        by gtall ( 79522 )

        "Steam engines and combustion engines"...they have nothing to do with computing, comparing apples and ice bergs doesn't really advance the discussion.

        Few think about programming as it is, no amount of slathering layers of indirection and high level paradigms is going to change that. A problem space is just that, a problem space. Yer basic prole is not able to specify any problem sufficiently enough to propose any solution, giving the proles the tools to solve problems won't change that.

        What's more likely is

      • > And we don't need as many analog electronics engineers any more

        It would be interesting to compare the numbers from 40 years ago vs today. It just might be that as computers got easier to use 30-40 years ago, more people started using computers, so we ended up needing MORE "computer people", a lot more - rather than less.

        Non-programming programming has been around for a long, long time - Hypercard and Excel come to mind. It was suggested at the time that Hypercard-like systems were about to replace pro

        • I think that the issue here is that just as how we use more energy now not less, it's not how many programmers there are it's how they rank in the spectrum of import things. SO we do employ more people now then we used to when we were harvesting Whale oil for liquid fuel. But in terms of the scale of the energy industry it's proportionally fewer. This might well be true of analog engineers. It might grow as we certainly are not at the point where everything is software defined radio with only a tiny fin

      • Soon we won't need the ditch diggers since the connection you use cable for will be wireless.

        I don't see how that analogy is relevant because the laws of physics keep this from happening for bulk data transfers to and from homes. Spatial multiplexing is a lot more efficient with cable than with radio. This and spectrum allocation by national radio regulators place an aggregate throughput limit for all users of a particular radio tower, which led to $10 per gigabyte* overage prices for cellular data transfer in the 3G and 4G eras.

        * Source: "LTE Internet Installed FAQs" by Verizon Wireless

    • Re: (Score:2)

      by jon3k ( 691256 )
      I think for lots of small business applications it will work well, where the scope is relatively small. I essentially see this as an option to replace small Microsoft Access databases, simple intranet applications and complicated spreadsheets that many (probably most) business use today. The only people who should be worried are people who sit around all day writing internal, line of business CRUD [wikipedia.org] applications all day on Sharepoint, et al.

    • The tech industry has been trying to eliminate the need for the position of "software engineer" since the day it became a paid position. Cobol is a particular poignant example, as it was intended to make software development so simple that absolutely anyone could do it for themselves...and all they managed to do was introduce Cobol as yet another specialized skill that commands a high salary.

      This story "with our solution, you won't need programmers anymore!" has been told again, and again, and again. And,

    • Because building something has nothing to do with code, but with understanding the application domain. ...

      And that requires typing out code, because why?...


      A computer should be able to generate perfect code, if only you could provide the instructions how. For all this talk of design/architectural systems, there is still a lot of ambiguity involved in software development.


      I notice that there is lots of love for "layers" and "reusable code", but the only justifications for that is because writing that

      • Re: (Score:2)

        by pjt33 ( 739471 )

        A computer should be able to generate perfect code, if only you could provide the instructions how.

        Providing the instructions is generally called "programming".

        If you could just update a flow chart and the computer could re-write it, who would give a shit about layers or re-use?

        Everyone who has to maintain a flow chart with more than a couple of dozen elements. Put another way, current programming languages are a textual representation of flow charts. Changing the representation to a less compact one won't

  • Nope (Score:5, Insightful)

    by gweihir ( 88907 ) on Sunday February 23, 2020 @03:47AM (#59756206)

    They will merely allow ordinary people to write simple things. Anything more complex is barred to most of humanity, because it requires not only understanding of the problem (which most already fail at), but also understanding of the mechanism executing it. Otherwise you get no performance, reliability, maintainability or security.

    Lets face it: Programming is one of the harder engineering disciplines. We do allow ordinary people to hammer in a nail or glue a hook to the wall above the sink. We do not allow them to build bridges or wire a house. Yet in programming, we do allow them to build whatever, no qualifications required. The results are as expected. That has to stop.

    Low-code/no-code will allow ordinary people to hammer in that nail, but not more.

    • I used to work with a Windows admin who was adamant that Sharepoint (a new tool at the time) was going to eliminate the need for web developers like me - ordinary people would magically be able to build complex applications involving complex logic without even needing to understand the necessary logic behind what they were trying to do.

      He was a nice guy, but not the brightest bulb in the box.

      • Maybe the admin thought those apps and logic were complex only because Sharepoint makes a bloody chore out of the simplest things, like moving files and navigating folders.

        You can actually turn a Sharepoint site into something decent, but ironically it requires work (and lots of it) by those same web developers that were going to be made obsolete.
    • Well we could probably work toward AI writing most of the glue code that comprises most programmer jobs. Programming is not engineering, regardless of what programmers call themselves. One trivial example to demonstrate that is that nobody anywhere is pushing "unskilled engineering," the obvious parallel to "no code programming." Consider for a moment what that would mean. Widely-marketed consumer electronics or bridges or bionic body parts designed by novices. I think Java and lately Python aim to give u

      • Re: (Score:2)

        by gweihir ( 88907 )

        Nope. Glue code needs even more understanding of what is going on. And no, programming is engineering. The problem is that most programmers are not engineers.

    • Well said.
      A problem is there's no way to _only_ let them hammer that nail, they'll try more advanced things and Rube Goldberg it all up, creating nightmares in maintenance.

      The issue is that making it possible for the unskilled to write program is going to get us some really nasty stuff. You know the vendors will not restrain them, but rather keep up the feeping creaturisms and "Now, with the ability to do things outside sandboxes! No need for security that gets in your way!".

      • Re: (Score:3)

        by gweihir ( 88907 )

        Well said.

        Thanks.

        A problem is there's no way to _only_ let them hammer that nail, they'll try more advanced things and Rube Goldberg it all up, creating nightmares in maintenance.

        The issue is that making it possible for the unskilled to write program is going to get us some really nasty stuff. You know the vendors will not restrain them, but rather keep up the feeping creaturisms and "Now, with the ability to do things outside sandboxes! No need for security that gets in your way!".

        For a time only, I hope. Anybody was allowed to wire up their homes, until enough managed not not only burn their own down, but also the neighboring ones. Then this idiocy stopped. I guess bad and amateur coders need indeed do a lot more damage though before something is being done. Eventually, liability and insurers may solve that problem though.

    • Most of the low-hanging fruit for "no code" has already been taken by Wordpress. So anything new will compete against Wordpress.

      Although modern frontend makes things WAY harder than they need to be. All that react on websites? Mostly unnecessary Javascript.

  • 4G programming again? (Score:3, Informative)

    by MikeTheBike ( 802199 ) on Sunday February 23, 2020 @03:50AM (#59756212)
    Oh well... it's not like this has been tried before and failed miserably... https://en.m.wikipedia.org/wik... [wikipedia.org] I would suggest that things like trust in and maintenance of the generated code may bring a huge headache... It will be a new niche solution but I pity the fools going down this route as it will cost them dearly! But hey, I've been wrong before and we need to expand the masses that program for a living so bring it on... I won't be joining you!

  • derp (Score:5, Insightful)

    by nyet ( 19118 ) on Sunday February 23, 2020 @04:00AM (#59756214) Homepage

    Ya let's leave rocket science, medicine, bridge engineering, airplane design, jet piloting to complete idiots as well, to lower the costs.

    Didn't Boeing try that?

    Fucking morons at Forbes.

  • Excelization (Score:5, Informative)

    by fph il quozientatore ( 971015 ) on Sunday February 23, 2020 @04:01AM (#59756216)
    Not sure what "no code" means, but it looks a lot like employees mis-using Excel to built horrible contraptions.
  • This is one of the dumbest things I've ever read

  • We've tried this already. It didn't work. (Score:5, Insightful)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Sunday February 23, 2020 @04:15AM (#59756232)

    In the 90ies they were called Case Tools - Computer Aided System Engineering. The problem is that 1.5 levels of complexity into your program you already have so many exclusive edge cases and functionality that you might as well just go back to pure code altogether. Otherwise you end up bolting onto your "low code" system with strange hacks and it's a big mess once again.

    What does work to a certain degree are DMIs - direct manipulation interfaces. A good example being Squeak or the former Flash IDE. You use these to start by building the visual gui representation of your objects and classes. It works pretty well, but these systems have a learning curve as well and the true party is in the code with those as well. But they are good for speedy Ux Ui development. Check out Flutter for something like this.

    Other than that I'm highly sceptical of the current case tool fad called "low code". I don't expect it to go anywhere meaningful because of the reasons mentioned above.

    • Actually we did try it and it sort of did work. In fact I'd argue (somewhat trollishly) that we're so deeply embedded in it that we don't even realise.

      In the beginning there was machine code.

      Just about everything since then has basically been there to stop people writing code. It started off with assembly, then COBOL and FORTRAN, because people wanted to write low code and just put down the business stuff or mathematical formulae and have the computer figure out the code.

      As languages get more powerful they

      • Agreed to a point. But, IMO, speaking in generalities and realizing there are exceptions: the ever-increasing levels of abstraction have lowered the bar to entry into the software development profession, resulting in a whole generation of "programmers" who do just fine when everything goes well, but can't understand all the layers they've built atop, so, when things go wrong, they can't understand it; or, worse, they design things in ways that professional software developers never would, by definition, s
    • I've used and written many tools for rapidly churning out crud and oltp apps/portions of apps over the years. There are some sweet spots:

      If you have a common pattern (like crud) repeated 100's to 1,000's of times in your enterprise app, then code gen is a real time saver.

      For more varied apps that don't follow consistent patterns, you just need to make sure that you don't try to fully encompass the entire process or you do hit all of those edge cases. You need to design the code gen/automation it as a

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday February 23, 2020 @04:25AM (#59756246)
    Comment removed based on user account deletion

    • Re:Why, yes! (Score:5, Insightful)

      by nyet ( 19118 ) on Sunday February 23, 2020 @04:32AM (#59756256) Homepage

      Or the way Boeing revolutionized aircraft production by removing expensive engineering and testing from the design and manufacturing process.

      • It's never an easy transition. But the losses were within acceptable range so the commodification and devaluing of that labor can continue. I, for one, welcome our wise corporate masters!

    • Exactly. What software does is AUTOMATE processes. If you doubt that the task of creating software itself can also be automated, you're probably in the wrong business. And, I say, thank you, thank you! Good heavens, I never, ever want to go back to the days before git, for example. I never, ever want to go back to the days when I had to provision my own servers. *shudder*

      Bring. It. On.

    • Yeah, actually. Most houses built in the last few decades have at least some prefabricated parts. The roofs are almost always prefab unless you have some special custom job, because those are an order of magnitude more complicated than walls. If you have a two or three story house, the layer between floors is often prefabricated as well. It results in a better end product.
  • We've been down this path countless times before. The complexity gets moved from one place to another but it's still there, usually dealing with all the bullshit edge cases or performance issues that distinguish one user from another user.
  • Comment removed based on user account deletion

  • I don't want to hear the word "democratization" (Score:5, Insightful)

    by peppepz ( 1311345 ) on Sunday February 23, 2020 @04:55AM (#59756286)
    As others have said in this discussion, the complexity of software reflects the complexity of the reality of the problems that it deals with. "Non-software" or "low-software" implementations can solve simple problems, but as people demand more features from them, or more quality, they will tend to become software, and therefore require a programmer.

    The point I'd like to add is that I oppose the use of terms such as "democratization of expertise". The opposite of democracy is tyranny. People who have competence are not tyrants. Knowledge is available for anyone to study and bring to fruition.
    Expressions like these belong to the populist rethoric and using them won't help unskilled people; it will only spread hate and ignorance a little more.

    • Being pedantic here, but the opposite of democracy is not tyranny, it's ochlocraty (i.e. when a majority-vote system starts opressing).

      Tyranny is the opposite of monarchy (i.e. when a single-ruler system starts opressing).

      You could also argure thay the opposite of democracy is monarchy. But then, still, the opposite of tyranny is ochlocraty, noy democracy.

  • Oh, yeah, like VB and Java... Write once, debug everywhere.

  • No it won't. It is a software design anti-pattern. We've been through this, 14 years ago!

    https://thedailywtf.com/articl... [thedailywtf.com]

    I mean "Enterprise Rules Engine"? Hello?
    https://thedailywtf.com/articl... [thedailywtf.com]

    • Re: (Score:2)

      by gweihir ( 88907 )

      This has happened a few times already. The first I personally saw was the 5GL (5th Generation Language) project that abysmally failed in the 1980s. My guess is that was not the first one of these utterly stupid attempts either.

      If you want solid engineering, you need good engineers and they are expensive. Software is not any different, except that many of the people making the decisions about who to hire are exceptionally and persistently stupid.

  • There have been many attempts to do this over the years, I guess stuff like Huron/Objectstar, Natural, SuperNatural etc. on the mainframe and dozens of tools on PC platforms.

    They all tended to be 80% solutions, if your problem domain fitted the niche of the tool. When it came to performance, the other 20% etc. they rapidly became more complex than traditional tools to achieve with lots of hacks to get around the shortfalls. Even if later versions addressed some of the points there were already solutions
    • Ayup, these tools can easily do 80% of what you need, but for that the remaining 20% is the actual important part which, thanks to the hidden complexities of the new magical toolbox is now 800% more difficult to do...

      • Re: (Score:2)

        by gweihir ( 88907 )

        Well said. Matches my observations perfectly. People have some early "success", but they never manage to create an acceptable end-product with these things. It is like trying to build a house with silly-putty.

  • Those were good ways for a few consultants to make lots of money, with no usable results at the end of the day.

  • ...from Tao Te Ching, Ch. 74:

    Trying to control the future

    is like trying to take the master carpenter's place.

    When you handle the master carpenter's tools,

    chances are that you'll cut your hand.

  • Nah (Score:2)

    by sjames ( 1099 )

    But there is some promising tech [youtu.be] to replace the CEO and most of the board.

  • We can and do automate classes of applications that have very high similarity (like sales applications or invoicing applications which aren't all that different from each other), with configuration options to take care of minor differences. But soon enough those 'configuration options' grow into a (usually ad-hoc and badly defined) programming language, and then we're back to square one.

  • This discussion has popped up every other year for the last 60+ years, starting with Algol, Fortran and Cobol, stopping over at SQL, Visual Basic, Excel and all the point-click-profit tools, past and present. In their time, they were all meant to "democratize" programming, but LISP and Assembler (and all their spiritual descendants) are still with us.

    It's like nuclear fusion: always ten years into the future.

    My take: by all means give people some hammers and some wrenches, I'll happily write them an invoice

  • There have been visual programming tools, we have libraries, we have Stack Overflow, ... Who precisely is coding anything 'from scratch'?

    The idea that somehow there would be 'no need for programming' doesn't really have any backing in reality. Yes, we have had CMS tools for the web for a long while, and we've had sites which allowed people to create their sites easily. And yet most companies still pay web developers. And yes, artists can create full games in Unity without programming knowledge. Yet games ty

  • It has not really been only about code for quite some time. It is about the ability to version easily the code (git), unit tests, being able to add easily new features and have usable tools to create applications, not awful buggy tools. So far, every single magical codeless stack was unable to work around those issues.
    Then, when you have your good tools, you enter the kingdom of undefined requirements and wacky business rules. Unless your customer accepts to simplify his/her business rules, you will probab

  • Simulink is heavily used in multiple industries. (Score:4, Interesting)

    by 0100010001010011 ( 652467 ) on Sunday February 23, 2020 @07:33AM (#59756436)

    Designed to let controls engineers 'write' certified control algorithms.

  • because people who do not know that they are doing clicking barely working, and likely even more insecure, system together :-/ brave new world.

  • will hypercards do away with traditional programming.
    oh. no? okay then.

    that's just now how any of it works. if you don't know what you actually want the app to do it doesn't matter if you're trying to create it with qbasic, excel, assembler or any number of non programming wiring platforms.

  • Because if we are, "lots of code" developers have nothing to worry about. I tried to prototype some simple stuff with PowerApps and Flow, and my conclusions have been that a) the set of things that can be done with those tools does not intersect the set of things that businesses actually need to do, and b) anything in the former set can be done quicker, better, and cheaper by someone who took a two-day class in Visual Basic for Applications

  • From the IT manager's perspective, this may well be true as Gartner predicts and certainly, at least in part, because Gartner predicts it will be true.

    However, on-the-ground work where developers are continuously driven to make reality appear to match the universe that management lives in while also working hard to develop whatever crazy thing sales sold customers, usually quickly after customers actually request it or complain about it not working.

    In reality, development tools and process management have b

  • If I rolled my eyes any more than I already am, I'd be at risk for an aneurism.

  • Comment removed based on user account deletion

  • I've been coding since I was 10 years old in 1981 and ever since then we've had various pieces of software that have promised apps and games without coding and while most can deliver something usable most fall flat if you start think outside the box they've designed for you.

    There are thousands of problems to be solved by software coding, these "app creation kits" have been around for over 30 years and they all produce the same software with very small minor variations. The most obvious examples where the Sh

  • We've had low/no code solutions for a while now: Microsoft Excel, VB, Access. The problem with these solutions have historically been that while they can solve real organization problems, they are effectively single user. Access maybe 3-4 concurrent users. The database/data-store has been very weak. That has always been the core problem for these kinds of solutions.

    Bring in today's low code/no code solutions, like, say, Salesforce. These present a default on-the-web presence (but what about security?) and a

  • If Nadella and others wanted to have a bigger impact, they'd figure out how to "Democratize Executives". When executives and management can be replaced by point-n-click interfaces, then no one ever has to suffer under bad management or corrupt CEOs again.

    But that's not what they're doing. They're trying to reduce the pay and impact of expert programmers to increase their own power and wealth.

    It is not about making technology more universally accessible, its about making power and wealth less accessible an

  • Once you get past the most trivial cases, most low-code solutions require highly paid consultants to do anything. If you build with one of these platforms, you can expect to pay both the platform provider and their consultants in perpetuity.
  • Companies have been building systems that can be used as drop in solutions with user customization for as long as there have been general purpose computers. They continue to improve, and every year they handle things they could not handle before, but all they are doing is giving companies more options when trying to decide how custom of a solution they need for their particular needs.

    Though I am esp annoyed (though not surprised) at yet another writer who does not seem to realize that not every company is
  • Don't be lazy. If you start headlines with a question, then your article is pretty damned shitty.
  • Lookup RAD and JAD popular in 1990 TI COOLGEN and various rebrands. By far the most ambitious with several output targets Model 204 Amdahl had one Apple computers had a low code builder - and it was good Visual Basic drag and drop can appear to do things - but never enterprise worthy I believe FOXPRO was also impressive, as were offerings from Borland. SAS was good until it became hideously expensive So SAP was born - and all the consultants etc mean no savings to be had All these products failed, because

  • At my job management decided to purchase one of these no code and low code automation solutions that lets you drag-and-drop activities to create a workflow like diagram that then executed as if it is a program. We used two different packages, the classic and NG next genration versions from the Ayehu company in the last few years.

    The guy in charge of running the solution is able to write scripts and he does a pretty decent job at it but he is not a programming wizard however he can get everything accomplish

Slashdot Top Deals

"It's like deja vu all over again." -- Yogi Berra

Close