When you hear something being described as "empowering" you can be pretty sure it'll be crap.
Google's Cloud Next OnAir broadcast marathon (56 days and counting) has run into its final week, this one focused on "Business Applications", with the claim its new product "empower[s] non-technical employees to quickly build data-driven applications without coding." Where have we heard that before? Perhaps from Microsoft, …
Agreed. We all threw up our hands at this when Microsoft suggested they were going to help non-technical users. We all know that this is going to be the typical shadow IT routine, where things will lie hidden somewhere until they break, then it'll be our problem.
However, that'll be long after the geniuses in the organisation who thought this would be a good idea have picked up their bonuses and left.
Where I work tried a 'low code' 'solution' (nameless to protect the criminal) which I got some training on. My impression was of the 'solution' is was actually much harder to work with than writing code in the traditional manner. I seriously doubt non-programmers could actually get something that works and programmers were frustrated by the inability to fix problems efficiently.
Low code solutions have to so modular that one can literally 'drag-and-drop' modules into the code and it will work. But one of the major problems I have seen is the backend code is often so bad that any competent programmer will vomit when they see it.
Of course, but now with so many DB types understood, DB admins also have more job security. Remember way back when admins (or someone) used to hide C: or D: or whatever, but all you had to do was type that in manually for access... this move has that type of foreshadowing.
I have no idea why you should give anything, people or machine, access to protocols that have no business using them. However, the sunny side is that this does give hope to prisoners as they may soon be making not just license plates, but firearms.
FFS... programming is hard. Programming is technical. It's hard to lay out a process in a logical concise order that can be maintained. It's hard to consider edge cases. It's hard to translate vague requirements into solid specifications.
The problem is NOT that language X is hard to learn.
Programming *languages* are the easy part of the job. Learn the syntaxes, learn the standard libraries, learn language-specific design patterns and you're fairly productive in a new language.
Too many people (managers, CEOs, and some entire software companies) think programming is just lots of typing, and if it wasn't so hard to "learn C" or "learn Java" ("I tried that learn Java in 21 days and gave up after a month") anyone could program, and "programmers" would not be needed.
See also: Excel, LabVIEW, Java (in some contexts).
"The company has now introduced AppSheet Automation, which lets non-technical folk automate existing processes. "
So... its a macro?
Look I'll admit i'm not a dev or a programmer, but I've read this entire article and frankly I still dont know a) what it's talking about, and b) why on Earth anyone would want it?
If you want to code something in your business, you either hire a dev to do it for you, or look if the solution already exists somewhere else (it likely does). If you have the enough time to learn how to use this AppSheet program, then you probably have enough time to actually learn how to program it properly.
I can only remember one occasion where I've talked to our IT department and asked if they could create a special program for my department (nothing fancy - just converting a Spreadsheet into a checkable interface and then running a program based on the inputs). Could I have whipped up something in this Appsheet? Sounds like probably yes, with enough time to learn what I was doing, plus debugging, and testing. Would I trust what I've whipped up to be utilised by my entire department? Hell No. So I'm really failing to see the use of this sort of program. I can also think of a couple of colleagues who if they were offered such a program, would use it for everything, and well that way leads disaster...
So thanks, but no thanks...
Not a dev, nor a programmer. I am an electrician so I do PLC programming, but that's ladder logic.
I work for a very old fashioned company. One that could burn a ream of paper per day on paperwork for 30 employees. Every job we do goes on a seperate material sheet, sometimes up to 10 sheets per day. Every day we write out the jobs we do on a time sheet. Every job we do starts with a work order, printed in duplicate so the office has a copy and the field as well. There is no IT department, no IT guy, no MSP, it's the boss and I who fix/build anything that's needed.
I tried appsheet about 3 weeks ago. I built the app based on how the material and time sheets were laid out on paper. I use it every day, though I know it's clunky and because of some flaw I can't find I cannot duplicate the date in appsheets and have to manually fix them in the spreadsheet. Another app converts the spreadsheet data to a form that is familiar to the office staff and I send the forms once a day to the office. Having the app on my phone is convenient, so for me this has been a win.
The office staff, appreciative as they are that they have legible paperwork from me finally, then prints out the forms and manually types them back into the "field service management software". They refuse to cut/paste...
At least, in the Who Me ? articles that are undoubtedly going to follow.
And I really look forward to reading about how an 'empowered' employee was able to trash a cloud-based database of critical customer data that didn't have any backup because said employee didn't think of setting one up.
Biting the hand that feeds IT © 1998–2020