|
|
Which went back to coding in ILE. Ah the joys of RPG calcsheets.
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Now that reminds me of a time we (my boss) thought to do the same. The project was scuttled after we tested the proof of concept on fellow employees and managers. They couldn’t/wouldn’t do it, so we decided against rolling out to clients.  
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Like trying to program your smart TV with the remote.
Quote: and yes I know THEY "think" and THEY "say ..."
THEY are the THEM. It's all a conspiracy created by the pronoun police.
Nothing succeeds like a budgie without teeth.
To err is human, to arr is pirate.
|
|
|
|
|
No-code systems are just a framework to the max. Convention over configuration.
|
|
|
|
|
I was mouth open amazed that I only learned yesterday, that Azure Portal, the web site, has a command line button, at top, which opens, in page, a terminal to do all your work. and can select to do in bash or powershell
i tottaly suck at using command line, but was like wow, all those guides which use terminal only be very useful.
|
|
|
|
|
You seem to assume it's SQL Server, but it may not be, and even if it is it may not be next year. If you code against the database directly your work will break when the data is moved, to another server, another database system, or whatever. I imagine the system designers want to prevent that.
The system is not there for your convenience, it's there to benefit the business and you are presumably engaged for your professional skills in working with it.
Why not suggest improvements to the interface that would simplify matters, instead of ranting that it doesn't suit your skill level? If you can show how much time and cost they would save, you might find them welcomed....
|
|
|
|
|
What you are saying may be right on some level. The OP wants to vent. Let’s let him do that.
And why don’t you pull your lip over your face and swallow.
|
|
|
|
|
My suggestion was more sensible, and more likely to achieve a useful outcome.
Anyway a 'nocode' system suggests that you don't write SQL code to use it. The questioner doesn't say but I inferred that the API returns data structured in some way (maybe JSON, maybe XML, maybe some other technique that you have to further work with. The intent must be to decouple the data repository from the user, and apart from security that usually is to ensure that if/when the data repository is changed the client side doesn't break.
|
|
|
|
|
haughtonomous wrote: The intent must be to ...
And they might have even rationalized the design that way.
But very seldom does it work.
Adding complexity because something might happen in an unknown future is almost always guaranteed to lead to increased maintenance costs.
And more coupling. That is because the API/interface was not in fact designed to be independent but rather was designed as a wrapper for the existing functionality. So in other words instead of starting with business requirements they started with the functional definition of the very system they are trying to make it independent from.
|
|
|
|
|
The criticism here seems to be confusing the idea with the implementation. Maybe this one wasn't well implemented, maybe so far few, if any, such systems have been because it is a hard nut to crack and as is normal, people are still working out how to do it well. But the idea is just another evolutionary step in software development - and 'proper programmers' are naturally very defensive about preserving their occupation. IMHO their arguments against the nocode idea are no different in intent than the unnecessarily convoluted and opaque documents produced by lawyers, for example, to protect their profession against redundancy. At its heart the nocode idea is just another level of abstraction and decoupling, both important principals in software, but the more of this you have, the less flexibility and more constraints you have on what you can do, and that can be frustrating. Horses for courses.
And of course any well designed system will lend itself to catering for what might happen in future, because otherwise it will have a very short life!
|
|
|
|
|
I think the heart of the problem is all these "no code" systems, fully commit into themselves and leave no room for traditional coding or scripting. I can't stress how much I hate "Flow" and "Power Automate" because of this.
These systems need to be more like the Office/VBA marriage. Sure... you can do some mighty complex stuff in Excel... and spread your calculations and sub-calculations across multiple columns and worksheets and everything... BUT... if you know how to write some VBA code, you can do all that work in a macro much faster. Traditional Excel for the "benefit of businesses" and the "code" side for the power users and developers.
|
|
|
|
|
Migrating to a different DB would mean re-writing the SQL anyway, plus possible changes to the interface as well. I don't see how removing the ability to work directly with SQL would help with this, unless the people using the system can't be trusted with SQL (in which case, maybe there are bigger problems).
I also don't get how you can design the structure and indexing on a DB without knowing how the data is going to be used.
|
|
|
|
|
The great thing about no-code systems is that you create more coding jobs. What about AI? Well, someone has to code those systems too. The problem is like you found, the interface layer will drive a tech-minded person insane because these tools are not made for us. They are made for and sold to managers who spent time in a marketing seminar watching a few examples that were perfectly crafted for the data. They pay incredible amounts of money for a tool that doesn't require health insurance and think they are saving a bundle. Suddenly there's a job opening for a SharePoint/App manager, and too often, it ends up being some non-tech-minded ex-business manager and friend of the HR lady you can't stand that suckered their last organization into moving everything to the cloud...and they need to hire some fakers - "tech-minded" assistants - to actually do the work, and they bother you all day because they can't figure out how to Google.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
|
|
|
|
I'm actually working on building a no-code tool for our staff to use for custom reports for our customers, and I'm trying to avoid "... only a real tech can actually figure it out" at all costs. I am putting a great deal of effort into making it make sense and be easy for those with little to no clue about SQL to be able to generate these reports without having to go into the db themselves or waiting for us to do it for them. I wonder if I can do it - make it easier/quicker for those who are uncomfortable with SQL, and maybe no harder nor slower for us.
I'm giving it my best shot.
|
|
|
|
|
Yeah, many of these are a joke, just as you describe.
The vendors oversell the systems, showing shiny examples of working systems neglecting to tell the potential customers that they were either built out by the vendor, at a silly cost, or built by customers who threw their IT department at the project.
I actually sat in on a zoom meeting where I had to explain the SQL to the vendor. I turned off my video and audio after a while and explained it to my dog sitting next to me. She at least tilted her head; which beat the blank stares from the vendor's so-called SA and Dev. 
|
|
|
|
|
"Working as intended".
Companies sell this stuff to those in charge who don't know any better.
They sell it as a way to "not require actual techies to manage, selling the idea that the company will save money by not needing to hire full techs. Instead they can hire low level techs that don't really understand how things work. The higher level techs that actually understood everything got tired of being locked out of making improvements and left for a company that values their skills.
All the time, the vendor is pulling the company in deeper the more systems they set up for them. Eventually the company is left with nothing but low level techs that only understand the cookie cutter system that the company is now locked into paying for. With no way to innovate and adapt.
Companies beware. You want to be successful, hire smart people that understand the system and can design the system you need to continue being successful.
|
|
|
|
|
This makes me thing of a soldering project from a while ago. It came with a couple pushbuttons and an instruction sheet on how to get stuff done with those pushbuttons. Not exactly impossible, far from that, but I found that digging through the code & uploading a custom binary to the MCU is sooooo less hassle than controlling this thing with the buttons.
|
|
|
|
|
I think that is the basic problem with these "no-code" platforms. They all assume that whatever data they need is a ready for them, all packages up with a bow on top.
The reality is most data is a mess, or wasn't designed for this particular set of views that the no-code app is expecting. You still need someone to apply a set of views or similar to pull in meaningfull data in a format that makes sense for that particular application.
I do not see developers losing their jobs over no-code systems. Maybe our hair from pulling it out in frustration.... 😜
|
|
|
|
|
Vendors have been trying this nonsense for years with the hopes that something will work to allow them to acquire a large share of the development market.
It has never worked and never will.
Users simply do not have the training to handle technical details as we do.
But idiots will keep on trying until this fad goes the way of all the others...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Clearly this will be an unpopular opinion here, but I believe low/no-code has its place. And honestly I've seen it proven out a few times where I work. I agree that it will never replace full development in all instances, but there are times when having a developer or even an intelligent power user quickly (point #1) build out simple (point #2) solutions with very little interference from security (point #3). At least this is what I have seen first-hand in the projects that have succeeded at my place of work.
The "inflexibility" of low/no-code is, in my opinion, guardrails preventing the power user from destroying more than a few decks of the Deathstar. If you want the whole thing blown up, that's when you need a full stack developer!
|
|
|
|
|
You aren't the only professional developer that has a distaste for low-code/no-code. I recently did something in low-code/no-code just to try to please management. The program ran horridly slow, had poor version control and was difficult to debug. Now, I'm nearly finished rewriting the equivalent program in a conventional language and the former issues are gone.
In this particular case, the conventional language solution is far superior to the low-code/no-code solution.
|
|
|
|
|
Just wait till they discover COBOL. Anybody can read or write COBOL code (even managers) because it's in human language! 
|
|
|
|
|
I worked for a startup company developing such a tool and put many years of thought into it. The goal, of course, was to come up with a way to simplify mobile application development to reduce the time and skill needed to generate an app. It started with trying to do as much as possible with drag and drop in some sort of visual interface. We generated many custom mobile apps with the system for customers, but what we learned that you can only do so much with drag and drop, more custom control was needed. So we allowed more detailed configuration via direct manipulation of the underlying data. Then we learned, configuration can only take you so far, more control was needed. It turns out, there are some things that are actually easier and more concise to define in code than configuration or drag and drop! Trying to break down code into configurable data, at some point actually becomes more complicated than the code you are trying to replace. Then we started looking into defining our own scripting language, our own debugger, etc... which was crazy. So here we are trying to eliminate code and it came full circle and we are trying to define a new language. It failed in the end. I think a better approach is to actually build similar tools, but build it on an existing language like C++. Don't try to eliminate the developer, but give him tools to generate code and dramatically improve productivity. Go after the best of both worlds. You get the best possible end result with native generated C++ code, best possible user interface, best possible performance, and if customization is necessary (it always is), you are building on the best possible language with the best extensibility, cross platform at the code level, etc... What say you?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
