Low-Code-No-Code Bloatware
-
Well, in the training class I had, the instructor couldn't explain why some of the labs didn't work. That's a bad indicator right there. Months later I flew to Tampa because the BizTalk project they were building wasn't working. When we met in the room with the numerous programmers, they had literally printed out the workflow of the project and taped it to the walls. Note, I said 'walls', not wall. It went 1/3 of the first wall (about 6 feet), around the corner down the entire next wall (about 15 feet), and around the corner on the next wall for another 3 feet or so. It was all I could do not to break into hysterics. All I could think was, are you people serious?
Member 14840496 wrote:
in the training class I had, the instructor couldn't explain why some of the labs didn't work. That's a bad indicator right there.
:laugh: :thumbsup:
-
I concur. I've been using SSIS for the last ten years -- leaving the easy stuff to my colleagues while I implement the difficult stuff in C# "Script Tasks". Before that, I was on a contract where they used an in-house "rule-based" system -- with a GUI to define which rules to use in what order, branching, etc. What if I need a new rule? Write it in VB. It's not much different in SQL Server either -- I write a lot of CLR functions in C# to deal with the hard stuff. Off-the-shelf tools contend only with low-hanging fruit. If all you have is low-hanging fruit, then an off-the-shelf tool may be sufficient. But no enterprise of significant complexity has only low-hanging fruit, so highly-skilled developers will still be required. But by all means let the highly-skilled developers concentrate on the difficult tasks while low-skilled developers work on the easy tasks in an off-the-shelf tool.
PIEBALDconsult wrote:
I write a lot of CLR functions in C#
Crikey in all my years of writing TSQL I never had to resort to the CLR, I guess I was only doing the simple stuff.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
PIEBALDconsult wrote:
I write a lot of CLR functions in C#
Crikey in all my years of writing TSQL I never had to resort to the CLR, I guess I was only doing the simple stuff.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Blessings counted.
-
Reading the Chris Maunder comment on the downward spiral of the industry, and along with the latest article by O'Reilly on low-code democratization of programming seems to never end. As with Chris, I have been doing programming since the first Radio Shack computers came out; and before that, using IBM punch cards to create wiring lists, paper tape readers to load programs, as well as cassette tapes. I guess people are doomed to repeat bad things when they do not have a history of the industry. I can remember low code apps. being sold decades ago. All flops. For a later lesson, take Microsoft's BizTalk. Preached as enabling power users and analysts to create programs without code. Like a company I worked for that spend 2 million dollars on a BizTalk project that failed because the gazillion objects it created simply choked the databases so bad that the throughput was like snail poop. After hiring additional consultants and create hundreds of 'functoids', the project was scrapped. For those not knowing what a functoid is, it's chunks of c# code used to do things that BizTalk could not accomplish in its so-called low-code IDE. All this relates the infamous 'black-box' approach using some of Billy-Bob's code that is supposed to work. But what happens when you find it not working? Google to see if Handy-Andy's code will work? Low-code, and especially no-code solutions of any magnitude, by default, are bloatware. As with BizTalk (huge bloatware), it usually chokes through-put.
"Kids are cute when they think they invent stuff" comes to mind rather often when on online forums. I don't think all of them are younglings never seen anything, I rather think it's the general attention span of a geriatric fly. Or maybe the desire for drama. That, of course, is best served by repeating it.
-
Reading the Chris Maunder comment on the downward spiral of the industry, and along with the latest article by O'Reilly on low-code democratization of programming seems to never end. As with Chris, I have been doing programming since the first Radio Shack computers came out; and before that, using IBM punch cards to create wiring lists, paper tape readers to load programs, as well as cassette tapes. I guess people are doomed to repeat bad things when they do not have a history of the industry. I can remember low code apps. being sold decades ago. All flops. For a later lesson, take Microsoft's BizTalk. Preached as enabling power users and analysts to create programs without code. Like a company I worked for that spend 2 million dollars on a BizTalk project that failed because the gazillion objects it created simply choked the databases so bad that the throughput was like snail poop. After hiring additional consultants and create hundreds of 'functoids', the project was scrapped. For those not knowing what a functoid is, it's chunks of c# code used to do things that BizTalk could not accomplish in its so-called low-code IDE. All this relates the infamous 'black-box' approach using some of Billy-Bob's code that is supposed to work. But what happens when you find it not working? Google to see if Handy-Andy's code will work? Low-code, and especially no-code solutions of any magnitude, by default, are bloatware. As with BizTalk (huge bloatware), it usually chokes through-put.
Is that the article citing how Excel is a great example of low-code democratisation? Reading that my first thought was " had this clown ever looked at any Excel spreadsheets designed by the 'democratised'"? Also, our favoured software supplier is very fond of providing solutions which have 'low-code' front ends for business numpties to 'develop' with (to protect them from doing any real harm) and they invariably make it impossible to do much more than change the colour of a font.... But hey!, the 'potential' is there for you to use... And, of course, Management (who will never, ever have to use it), buy into the crap and expect wonders from staff who have no idea what the hell they're doing....:mad:
-
Is that the article citing how Excel is a great example of low-code democratisation? Reading that my first thought was " had this clown ever looked at any Excel spreadsheets designed by the 'democratised'"? Also, our favoured software supplier is very fond of providing solutions which have 'low-code' front ends for business numpties to 'develop' with (to protect them from doing any real harm) and they invariably make it impossible to do much more than change the colour of a font.... But hey!, the 'potential' is there for you to use... And, of course, Management (who will never, ever have to use it), buy into the crap and expect wonders from staff who have no idea what the hell they're doing....:mad:
I thought similar things when reading that article. I once wrote a bit of code to use a database for powerlifting meets to replace a ghastly Excel solution they use. Their response? We don't want our members in a database :doh: So at every meet we copy the spreadsheet and use it and I dream of database structure and easy apps. Oh well.
-
Reading the Chris Maunder comment on the downward spiral of the industry, and along with the latest article by O'Reilly on low-code democratization of programming seems to never end. As with Chris, I have been doing programming since the first Radio Shack computers came out; and before that, using IBM punch cards to create wiring lists, paper tape readers to load programs, as well as cassette tapes. I guess people are doomed to repeat bad things when they do not have a history of the industry. I can remember low code apps. being sold decades ago. All flops. For a later lesson, take Microsoft's BizTalk. Preached as enabling power users and analysts to create programs without code. Like a company I worked for that spend 2 million dollars on a BizTalk project that failed because the gazillion objects it created simply choked the databases so bad that the throughput was like snail poop. After hiring additional consultants and create hundreds of 'functoids', the project was scrapped. For those not knowing what a functoid is, it's chunks of c# code used to do things that BizTalk could not accomplish in its so-called low-code IDE. All this relates the infamous 'black-box' approach using some of Billy-Bob's code that is supposed to work. But what happens when you find it not working? Google to see if Handy-Andy's code will work? Low-code, and especially no-code solutions of any magnitude, by default, are bloatware. As with BizTalk (huge bloatware), it usually chokes through-put.
I couldn't agree more and I have been programming probably as long as you have. I remember the efforts with "Magic PC", a product that promised to eliminate code altogether. A similar product has recently appeared but I have heard little about it's success. I also attended a seminar where Oracle demonstrated its "no-code" database application development environment. It started out well and good but as the demonstration application became ever more complicated, so too did the tasks that one had to perform top build it. About every 10 years, someone in the industry comes up with a new product that promises to be the panacea for businesses for the elimination of developers and software engineers. To date, not a single product has ever worked... and probably none ever will. This is because complex tasks require thought and innovation, which is something outside the box of these fads...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
PIEBALDconsult wrote:
I write a lot of CLR functions in C#
Crikey in all my years of writing TSQL I never had to resort to the CLR, I guess I was only doing the simple stuff.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Mycroft Holmes wrote:
PIEBALDconsult wrote:
I write a lot of CLR functions in C#
Crikey in all my years of writing TSQL I never had to resort to the CLR, I guess I was only doing the simple stuff.
My thought exactly. I've been writing SQL for over 30 years and TSQL for nearly 20 and, although I've played with some functions in CLR, I've never found a need for it in production code. I suppose the over 600,000 lines of SQL under version control in the main project at work is also all simple stuff! :)
-
I couldn't agree more and I have been programming probably as long as you have. I remember the efforts with "Magic PC", a product that promised to eliminate code altogether. A similar product has recently appeared but I have heard little about it's success. I also attended a seminar where Oracle demonstrated its "no-code" database application development environment. It started out well and good but as the demonstration application became ever more complicated, so too did the tasks that one had to perform top build it. About every 10 years, someone in the industry comes up with a new product that promises to be the panacea for businesses for the elimination of developers and software engineers. To date, not a single product has ever worked... and probably none ever will. This is because complex tasks require thought and innovation, which is something outside the box of these fads...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Right. Now there is some usage for SSIS packages in SQL. But these are relatively small/short ditties that, for example, sucks in a file and populates some data table, or spits out a file from some data. The problem is - all this creates code fragmentation. A little code in SSIS, a little in SQL, a little in C#, a little taste of jQuery/jScript, a GitHub file or two, et. al. So if you are not aware of all the pieces and parts to this basket of 'stuff', you can be stranded when you take it over from someone who created the mess unless someone provides you with a road map. Another goofball process created by those trying to prove their worth with little else to do is MFC. I once created a new MFC project in VS and sat there for a good 10 minutes while it loaded in literally a ton of support files. Tagged and sold to management (and some self-proclaimed gurus as the next best thing since fire), you don't hear a lot it about lately.
-
Reading the Chris Maunder comment on the downward spiral of the industry, and along with the latest article by O'Reilly on low-code democratization of programming seems to never end. As with Chris, I have been doing programming since the first Radio Shack computers came out; and before that, using IBM punch cards to create wiring lists, paper tape readers to load programs, as well as cassette tapes. I guess people are doomed to repeat bad things when they do not have a history of the industry. I can remember low code apps. being sold decades ago. All flops. For a later lesson, take Microsoft's BizTalk. Preached as enabling power users and analysts to create programs without code. Like a company I worked for that spend 2 million dollars on a BizTalk project that failed because the gazillion objects it created simply choked the databases so bad that the throughput was like snail poop. After hiring additional consultants and create hundreds of 'functoids', the project was scrapped. For those not knowing what a functoid is, it's chunks of c# code used to do things that BizTalk could not accomplish in its so-called low-code IDE. All this relates the infamous 'black-box' approach using some of Billy-Bob's code that is supposed to work. But what happens when you find it not working? Google to see if Handy-Andy's code will work? Low-code, and especially no-code solutions of any magnitude, by default, are bloatware. As with BizTalk (huge bloatware), it usually chokes through-put.
Instead of Microsoft spending money on no-code/low-code bloatware like PowerApps and Logic Apps, why not create a UI designer for XAML (Xamarin Forms, MAUI, etc.) and HTML/CSS (Blazor)? It is hard to find developers today who were not raised as "script kiddies. They prefer hacking out reams of UI code, and are confused that a UI designer can do a better job much faster - indeed, they have little concept of what rapid application development (RAD) is. Most of the ones I have talked to are surprised to learn that Alan Cooper's small team created the VB WinForms designer in a relatively short time. When I ask some of them (including the few MS program managers I talked to), they thought it would take huge teams several years to write a useful UI designer. That Alan Cooper and his small team did it in such a short time, with just as complicated a UI syntax as HTML or XAML, is news to them. Microsoft could hire a small team of sharp, knowledgeable individuals and get back to prominence in the area of RAD.
-
Instead of Microsoft spending money on no-code/low-code bloatware like PowerApps and Logic Apps, why not create a UI designer for XAML (Xamarin Forms, MAUI, etc.) and HTML/CSS (Blazor)? It is hard to find developers today who were not raised as "script kiddies. They prefer hacking out reams of UI code, and are confused that a UI designer can do a better job much faster - indeed, they have little concept of what rapid application development (RAD) is. Most of the ones I have talked to are surprised to learn that Alan Cooper's small team created the VB WinForms designer in a relatively short time. When I ask some of them (including the few MS program managers I talked to), they thought it would take huge teams several years to write a useful UI designer. That Alan Cooper and his small team did it in such a short time, with just as complicated a UI syntax as HTML or XAML, is news to them. Microsoft could hire a small team of sharp, knowledgeable individuals and get back to prominence in the area of RAD.
Good point. For business development, RAD development is a must. Sadly, some of these new languages are really not RAD. Say what you want about this one is good for this, and that one good for that, RAD is best for business development. While the original VB did not provide the vast abilities as C# now does, you could access the API if needed. But the speed of development was great because the entire syntax for VB could be printed out in a medium size binder - no intellisense needed. The only pitfall VB had was DLL hell, which with care, could be avoided. Except for Delphi, which I used for several years, I have not found any other RAD development environment that beats VisualStudio - specifically C# in my case.
-
Good point. For business development, RAD development is a must. Sadly, some of these new languages are really not RAD. Say what you want about this one is good for this, and that one good for that, RAD is best for business development. While the original VB did not provide the vast abilities as C# now does, you could access the API if needed. But the speed of development was great because the entire syntax for VB could be printed out in a medium size binder - no intellisense needed. The only pitfall VB had was DLL hell, which with care, could be avoided. Except for Delphi, which I used for several years, I have not found any other RAD development environment that beats VisualStudio - specifically C# in my case.
I was actually writing more to the point of a UI designer, not the language, being the RAD context. The fact that MS's UI designer in Visual Basic, before the days of Visual Studio (but the UI designer was carried over into Visual Studio as .NET came along) was the de facto RAD standard for UI development (that others like PowerBuilder tried to copy) says a lot about the concept of reducing UI development time to 1) reduce overall development time, 2) provide consistency while allowing manual changes, and 3) allowing more of the finite time devoted to a project to be spent on what has to be coded instead of grunt-level UI coding.
-
Reading the Chris Maunder comment on the downward spiral of the industry, and along with the latest article by O'Reilly on low-code democratization of programming seems to never end. As with Chris, I have been doing programming since the first Radio Shack computers came out; and before that, using IBM punch cards to create wiring lists, paper tape readers to load programs, as well as cassette tapes. I guess people are doomed to repeat bad things when they do not have a history of the industry. I can remember low code apps. being sold decades ago. All flops. For a later lesson, take Microsoft's BizTalk. Preached as enabling power users and analysts to create programs without code. Like a company I worked for that spend 2 million dollars on a BizTalk project that failed because the gazillion objects it created simply choked the databases so bad that the throughput was like snail poop. After hiring additional consultants and create hundreds of 'functoids', the project was scrapped. For those not knowing what a functoid is, it's chunks of c# code used to do things that BizTalk could not accomplish in its so-called low-code IDE. All this relates the infamous 'black-box' approach using some of Billy-Bob's code that is supposed to work. But what happens when you find it not working? Google to see if Handy-Andy's code will work? Low-code, and especially no-code solutions of any magnitude, by default, are bloatware. As with BizTalk (huge bloatware), it usually chokes through-put.
Check out OutSystems.com You can spin up a test environment for free to test drive it. They have good tutorials to help you learn it. I think of it as an alternate IDE/forward code generator for C# apps or a cloud-ready Microsoft Access. If you need to drop down to code C# or JavaScript, you can. Web or mobile. Need to tweak CSS, you can. It is a developer oriented low code platform. For web based LOB apps, it is hard to beat.
-
Check out OutSystems.com You can spin up a test environment for free to test drive it. They have good tutorials to help you learn it. I think of it as an alternate IDE/forward code generator for C# apps or a cloud-ready Microsoft Access. If you need to drop down to code C# or JavaScript, you can. Web or mobile. Need to tweak CSS, you can. It is a developer oriented low code platform. For web based LOB apps, it is hard to beat.
Okay, but this is a developer assist, not a user created application; which is what my original topic was about. BizTalk was supposed to be used by analysts/power users, which never happened. While probably automating some standard processes, at $4000/$10000 per month, it would be hard to justify that expense to many medium/smaller companies. That is $48,000/$120,000 per year. Not knocking the product here. From what I see, it probably does provide some time savings - but for a steep price. But I would still bet that in complex applications, you would still be adding code.