I think low code and AI have an incredible productive future. ChatGPT can create simple python programs right now. Imagine a few years from now, where it can output a low code program; that will be game changing since there won't be a need to have a software engineer to deal with the code. It's coming and it's coming fast.
Next to nothing eh. Tell us more about the technological complexity of what you're building... Because I'm already seeing good dev shops in India charge $30 and upwards, and while that's "nothing" compared to US salaries, it's non-negligible (and it has trade-offs).
True, cars may never drive themselves but I guarantee that at some point we'll have vehicles that have very specific functions self drive. I can even say that cars that self drive in the highway only are just around the corner.
No code won't fill all needs but they have a place in business.
Everyone is talking about chatgpt and code generation this week. I think the code generated with chatgpt might be 90% accurate but how confident would you be to deploy that in production. We know empirically that last 10% can take decades to get it right. Using gpt to generate a blob of content is different from using gpt to generate code.
>> I think low code and AI have an incredible productive future. ChatGPT can create simple python programs right now. Imagine a few years from now, where it can output a low code program; that will be game changing since there won't be a need to have a software engineer to deal with the code. It's coming and it's coming fast.
> Everyone is talking about chatgpt and code generation this week. I think the code generated with chatgpt might be 90% accurate but how confident would you be to deploy that in production.
I haven't been paying close attention, but all the code I've seen it generate is also very simple -- like the kind of stuff someone could write after taking an intro programming class, prompted by a pretty detailed specification.
Modern-day software engineers basically write detailed specifications, they don't translate specifications into "code." Whether you're writing "AI prompts" or Python, it'll still be software engineering. Though my gut feel is software engineering by prompts will feel like typing with a wet noodle to hit the keys.
Most complex one I saw this weekend was this [1], the point I'm trying to make is the even if you make generate complex stuff, if would take decades where we deploy this kind of workloads in real world scenarios.
Maybe it would be better to use AI on the test side of TDD. Have the AI listen to the requirements and write tests. Have the human write code to the tests and update the nonsensical parts of AI generated tests.
The problem is, creating the code isn't really the bottleneck. It's the stakeholder negotiation and conversations and understanding the business problem and updating the site when the business problem changes and updating the wording and changing the site because legal are unhappy with it then changing it back because the CEO overruled them and so on and so on.
What people aren't seeing is that this opens coding to a large number of people that only need minimum skills to create a solution. A determined business user can put together an app that takes an expert now. No code is targeted towards the users that have a relatively simple app but don"t have the skills, budget or time to learn a programming language. I've known people that have put together the needs requirements and design an app but don't have the skills to write it. That's the ideal market no code is aiming to get.
Software Engineers will have their place but no code and AI is aiming for the masses.
Low-code has been promised for the masses for ages, and has barely fulfilled that promise. I have seen a lot of non-techies come up from solutions, from websites or eCommerce stores, to little Zapier integrations, to a simple CRUD system with Airtable. Low-code is great for these use cases, but they're really simple. Anything beyond trivial complexity, these people generally stall and they need to hire designers or programmers. Hey, it's fantastic for that first 1% and that's already a lot, I'll give you that.
I actually think low-code will see a resurgence serving "almost technical" people such as tech business analysts, and also, drum roll... programmers. There is a current generation of maturing low-code tools (ex: Retool, PowerApps, Plasmic, Builder.io) which allow tech people to combine low-code and code as needed and which programmers may actually find attractive.
As for AI (ex: GPT), the main output it provides is code. It's nearly impossible to operate it at present for code-generation tasks without knowing how to code. Yes I think it's inevitable we will see a tool that blends current low-code graphical programming with NLP inputs. But it sounds very complex to make and I think it is likely to face the same base problems that low-code has.
I'm a programmer that has been in many situations where I've had to tell business users that I don't have the capacity to work on their project even though it's relatively simple. That's why I believe no code will be a great asset to companies.
As I said in my other comment, I agree that's the main use case for low-code. But I think it's largely going to be programmers or really techy business analysts doing the job, at least in the shorter term (next ~10 years).
Also, a thing people not considering with AI-assisted coding is that if it really makes programmers more productive, there'll be more chances to tend to more projects.
What good is a chatbot that can write code if nobody knows how to maintain the system that code runs on? In the time it takes to learn how to use AWS and administer servers to the point where you're not a massive liability, you could have learned JavaScript and Python from scratch (and learned actual Scratch while you're at it).
Yep, the auto-generated stuff is a nightmare to understand. I've found it hard even switching from the old monolith architecture to the new Cloudformation stuff. But maybe I'm just stupid
No, I believe the cloud stuff has evolved in a way that is just strange. I know I'm not stupid, and I look at this stuff with suspicion. This is why I'm going vertical by owning my entire stack (except Amazon S3 because it is awesome...)
I think it's just idiosyncrasies of one system create idiosyncrasies in next system that uses it.
Nobody would design it like that from scratch but having only already existing stuff to build on makes the end result more complex that the problem it solves requires
I know someone that is an executive at a F500 who does this with his team. According to him most divisions similar to his require a staff of 150-200 but he gets in done with 50 distributed around the world (mostly Poland & US). He tells me that he still has to argue for his budgets despite massive success and other adjacent coworkers get very toxic once they find out a division in the company pays good wages to their workers. Not only do they get good pay, but the SWEs love working in the org because their leaders regularly listen to them and employ solutions they suggest. There is very very little turnover in the rg.
You'd think the success of his model would be used elsewhere to reduce employer costs and increase retention (no SWE has left his org in 4 years). Instead other petty executives get pissy and poison the well.
Something is extremely off with modern corporate America.
What they don't get outside of Big Tech is that non-junior developers are (relative to the traditional pre-software 20th century industrial business model) more like managers than like line workers. It's just that the "workers" we manage are robots.
But even a pretty low level developer is going to end up making important business decisions just incidentally as part of their job, because it's hard to specify out every little decision that could impact the business without basically doing the dev's job for them.
Businesses can embrace that or they can ignore it at their peril.
I find that any company that actually gives its college-hires the formal job-title "Junior Developer" is not a good place to work: I interpret it as saying they don't respect their own employees. YMMV.
How would you name them then? In my experience many companies tend to give all the developers senior statuses even though they are actually still quite juniorish.
What’s wrong to be a Junior Developer?
I'd trim-off the "Junior" and leave it at that. For a formal job-title (as HR would demand) it's common to have Roman numerals appended, e.g. "SWE I" and "SWE II" before you get "Senior". The semantics is the same: "SWE I" == "Junior SWE" but without the
unpleasant connotations that the term "Junior" specifically has, especially when you have older folks coming in at an entry-level (e.g. from coding-camps or a midlife career change) where referring to a 40something as "Junior" just feels weird.
That's how it's done at all the US software companies I've worked at, including Microsoft and some startups.
My current company does has done away with job-titles entirely and we make up whatever we want on our business-cards (within reason).
Ok, seems like a good alternative. I didn’t know about it, in Germany it’s simply „Junior“ and „Senior“. If you are like a year or two in a company you usually are simply upgraded to „Senior“ no matter what.
Even though I wouldn’t consider Junior offensive I like the system you describe much more.
What managers don't get is that almost all roles are like that. In fact, I'm wondering if that "almost" word should be there at all.
Everybody organizes people, decide how work should be done, and has to make a lot of little decisions that nobody could anticipate. Not with the same leverage as developers, but with important consequences too. Somehow, management experts can't accept this.
I've come to believe that all labor is skilled, all that matters is how much training and/or experience is required to make them able to do the job that differs.
But that's kind of the point -all that matters is how much training and/or experience is required to make them able to do the job, but the differences can be quite large.
We establish a difference between jobs where that training is relatively short (and thus we can expect it to happen on-site by the company who can hire people from other positions and have them do the new job) and the jobs where that training takes many years and thus requires significant pre-commitment and long-term planning to ensure that they can be filled.
For the purposes of crude statistics we pick an arbitrary line and label the jobs with <1 year of job-specific training required (starting from generic knowledge e.g. highschool or a degree in some other field) as "unskilled" and >1 year job-specific training required as "skilled"; but the key point is that there is a substantial qualitative difference between roles where you can "swap" people from one industry to another, and roles where that doesn't make sense at scale - while some individuals do switch high-investment careers, you're not going to solve a pandemic-prelate doctor shortage by re-purposing excess lawyers, but in that same pandemic you can solve a delivery driver shortage by re-purposing excess cashiers. Similarly in IT, the jobs which can be done by putting someone through an x-week boot camp do need different treatment from managers and policy-makers than the tech jobs which do require much more training and/or experience.
I bet your friend works super hard to manage 50 people as well as you say. I was in the Navy and the primary way to make a division/department great was for the leader to work 2x as hard as their peers to make sure theor division/department was performing awesomely. I recall having to get up 2 hours early to review my division's maintenance schedule so I could do surprise spot-checks. Peers would let the 1st class PO choose the spot-checks, and of course they're going to chose the easiest and fastest ones to finish, rather than something representative of the most important maintenance that day. The thing is, my division wasn't angry at me for doing the hard spot-checks (or anything else I was a hard-ass about), because I also spent more time to make sure they got ranked at the top of the stack and fought for them to get more time off and freedoms even if my superiors got irritated at me, so they were willing to work hard and perform above the rest of the crew. Managers that suck and don't work as hard have shit teams.
In tech and other creative jobs: the better the developers are, the less (micro)management they need.
Bad managers thinks a managers role is all about making decisions. Great managers knows it's about enabling employees: great managers act more like secretaries, making sure everybody knows everything they need.
When a manager can communicate what is going on and what the strategy is, most decisions become obvious and this results in everybody agreeing to what needs to be done.
Something is extremely off with modern corporate America.
That’s because large corporations are typically run like communist states, where the workers have little say in their own work, and tyrannical unelected leadership sets up hierarchies that reward political infighting to build power.
Why don’t corporations try democracy and bottom-up decision-making? Is corporate capitalism incompatible with democracy?
> That’s because large corporations are typically run like communist states, where the workers have little say in their own work, and tyrannical unelected leadership sets up hierarchies that reward political infighting to build power.
You're describing capitalism, actually.
> try democracy and bottom-up decision-making
Those are called worker co-ops. They're very socialistic. And democratic. It's quite possible for them to be profitable, too.
Seems to be just jealousy. From what I gather the old CEO and CTO liked him and his successes/goals but other junior level executives did not.
When the new CEO was brought on they started to listen to the junior executives. They poison the well by stating things like how what he is doing isn't necessary or slowing down their own goals.
Just humans being humans. As a result he will likely leave in <2 years. I don't doubt that his old org will falter extremely fast.
It seems like well run orgs with less people are highly susceptible to quick change than large useless behemoths. Seems paradoxical, but a common fate at many companies/orgs.
The reason the boss man doesn't want to hear your thing is that it's basically super hard to get.
"Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good. The paying them a good salary and treating them well, companies are right onboard with in my experience. The tech department has better working conditions that most other departments. I worked at one company and one of the marketing teams once had to leave a resturant before eating because their lunch time ran out. So they paid for their food and left without it. All the techies just looked on in shock. We came and went as we wanted.
But the thing of finding good developers is hard. Even if you target just the folks in the top 50% of the bell curve, it's still going to be hard. And in my experience you get a few lower quality developers in and the next minute you've got someone saying their AWS lambda solutiuon can scale to any level 10 minutes after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling... I swear to god, even the non-technical folk knew the guy was talking nonsense. And the thing is, these people can and will pass your tech tests because honestly tech tests aren't really good at showing you how good a developer is actually understanding things. They can write quicksort but have no idea, how to figure out the best way to scale a data export feature that is crashing because of memory limits.
And the thing really with no-code, you encounter a bug, you're possibly dependent on a third party to fix the bug. Not a good place to be in because they never care as much as you do.
The humanity of being asked two simple questions about what work you're doing. It's shocking. I know. But I've worked at a few companies where they rolled the standup out to otherd departments.
If you honestly think being asked those 2 simple questions is not being treated well. You're going to have a hard life.
No single example on it’s own seems like such a big deal. But long hours, being on call, little respect, etc show IT is a low status profession that happens to pay reasonably well.
> IT is a low status profession that happens to pay reasonably well.
IMO this is absolutely crucial to understand about our industry, for programmers too, not just IT.
We're paid well because they can't avoid paying us well. But they don't want to let us in The Club of the actual professional or upper-middle class, in terms of perks and status (and, actually, pay in most of the industry, even in the US, doesn't quite rise to that level—$200k+ for mid-career-or-earlier isn't what most programmers see).
Frequent monitoring and things like open floorplan offices are part of that. High-status gets very little monitoring, and an office. There are tons of little things like this.
I think it may also be a minor reason our interviews are so god-awful (but I think the main reason is the huge players trying to reduce turnover to suppress the rate of wage increases).
I think a major reason interviews are so god-awful is that, due in large part to the high wages, there are a lot of frankly totally unqualified people seeking SWE positions. And when they fail an interview, they don’t dematerialize, but rather keep banging away hopelessly at the front door of the process.
When companies want a fully algorithmic way to filter for signal, it’s not because we think it’s a great process, but because it’s one of the only viable processes.
They don't measure "goodness", they merely check that the person actually knows how to write code. I disagree with them (I believe they are unnecessarily complex when it comes to the actual algorithms, and rarely mimic the real-world requirements of the job), but at least they do weed out idiots who can't even write a for loop.
There're shocking number of people who can't write simplest code.
Here's simple task that I ask on interviews: write JavaScript function which works like setTimeout and uses setTimeout internally but provides a Promise result so it can be awaited. Very few people can write that kind of code. They actually have no idea what Promise is. They want to get in frontend position. How can you write frontend code if you have no idea what Promise is.
I would say that's not a great example. I wrote literally that function as a utility in my project, and it was honestly kind of tricky. There's a big gap between knowing how to use a Promise, which is necessary and closer to an "idea what a Promise is", vs how to build one from scratch, which is nice but probably not necessary for a generic frontend job. It wasn't even really necessary for me, I just wanted to be able to pause functions with an await statement.
Imagine you had an automated oracle who could tell you how many out of three easy-level leetcode problems a candidate could solve in 90 minutes total.
Would that piece of information be helpful to you as you consider which candidates to invite to the first round of interviews? That is why companies do it.
A candidate who got 2 or 3 solved in 90 minutes is very likely to do much better on the rest of the interview and on the job than someone who couldn't solve any.
(I think a lot of people who can write code have a difficult time imagining just how many people both can't write code and apply for seemingly every posted SWE job listing.)
Also it is very difficult to assess someone's coding qualifications in an interview -- I feel like more difficult compared to other roles, although I'm interested in opposing opinions -- especially if the person doing the assessing isn't a coder themselves, but honestly either way.
It is just baffling that you think this. Have you worked in the service industry recently? Like about half of americans? Where you also work long hours, but don't have a set schedule, or health insurance, or pto. And are required to endure virtually any debasement a customer feels like exposing you to. And your behavior, appearance, comings and goings are rigidly governed by a handbook and enforced by petty tyrants enraged by also enduring all these same conditions?
Get some perspective ffs. This is the easiest, cushiest job I've ever had, and the only one where people with masters degrees often consider me their peer despite my 11th grade education.
Stop whining and join a union or something seriously. These are all minor and solvable problems.
That says more about you than the average developer. You may feel you won the lottery because you don't have to stack boxes in your hometown for minimum wage because of the limitations on a grade 11 education. That person who put in the effort/time/money to get that masters might feel left out of the club of his former peers run the show.
Please get some perspective not everyone is in your situation.
Many IT jobs are paid hourly, don’t get health insurance, and some even get paid minimum wage. That said, I have had plenty of people describe their retail jobs as cushy because it’s low physical labor, inside with AC, and they don’t have to think.
Is being on call really a sign of low status? I may be wrong, but I'm pretty sure most doctors have an on-call schedule. And if you think doctors aren't in a high-status profession, I reckon your standards are wildly different from my own.
Long hours and little respect probably will vary from one employer to the next. However, I've been working as a developer for about ~10 years - most of it with a mid-size insurance company but the last couple with a large bank. I work longer hours than most of my colleagues, but I've rarely put in more than 50 hours in a week, and my average is probably closer to 45. And my non-engineering colleagues have always treated my fellow engineers and me with respect and an appreciation for the difficulty of what we do. If anything, they've usually been a bit too deferential.
YMMV, but I think our profession is probably among the best in the world for workers. If my child were about to enter the working world and had the ability + interest, I'd absolutely recommend this as a career.
I don't think on call is a sign of low status, but I think OP is correct that programming is a low status job. People respect the business guys with the big ideas, not the implementors and tbh I think that's fair. It's still one of the best jobs in terms of benefits, but you have to be willing to accept that your life as a corporate programmer is mainly carrying out someone else's ideas.
Being on call is just one sign, just as IT is more than just programming. Also the vast majority of doctors, especially the high status ones aren’t on call.
However, being on call is representative of something. Your electric company has linemen ready to respond at 2AM because they provide a service which needs to be available 24/7. However, good luck trying to contact your dermatologist, accountant, physical trainer etc at 2AM.
For all practical purposes, above a certain level of management, you are implicitly on call all the time. However, the bar to clear to engage you gets higher the further up the leadership layers you go. A manager of a handful of teams comprising about 100 staff gets engaged for less serious fires than the CEO, but both are "on call". It might take the board of directors chartering a helicopter to get to the CEO's fly fishing cabin during the CEO's vacation if a situation warranting such presents itself, but the CEO is absolutely on call 24x7x365.
The complexity of what engages the on call person I suspect is what connotes status. Called for clearing out disk space: low status. Called for application outage that has stumped multiple technical teams: higher status. Called for a production outage impacting the next day's C-level reports that requires engaging other management: higher status. Called for heading off a shareholder proxy battle: even higher status.
Note here complexity doesn't solely reside in the technical realm, but frequently is rather a blend of technical factors, social factors, and quickly making impactful decisions in low-information situations.
Long hours, being on call, and not getting respect are bad things, and you should not work a job where they happen. That has absolutely zero relation to whether you're asked what you're working on.
The problem with the question is never liking the answer: "I'm probably gonna have to stare at the sky for 4-5 hours, and what you consider real work is gonna maybe start happening tomorrow."
I can't wait for low-code to get good. It's going to throw back in real time the obliqueness of the request:
"Validating most likely candidate solution..."
8 hrs later
"Solution failed to validate ... please try rephrasing request."
> I'm probably gonna have to stare at the sky for 4-5 hours, and what you consider real work is gonna maybe start happening tomorrow
It may not be indicative of the industry at large, but most engineers I know get away with this by changing the framing "I'm working on a doc" or "I'm scoping this feature" etc. Obviously this does not work with sufficiently bad management.
Daily interrogations by someone who finished a two-day "agile" course. Doctors don't have to put up with this. Or you could always get a better job that doesn't do "standups".
Doctors have to see multiple dozens of patients a day. Often their life sucks, have to sleep on the job in the hospital, etc. Never be envious with their plot, private capital sucks the juice out of everyone unlese we fight back.
Annoying as morning standups are, they are (well, should be) about keeping the team in sync and communicating, not about Big Brother watching you. Companies that want to be Big Brother have much more intrusive and insidious ways of doing that.
I am a disorganized guy who hates authority and interruptions, and even so I have grudgingly come to realize that (strictly) 15-minute morning standups actually do increase my productivity.
>Not a good place to be in because they never care as much as you do.
What you really want is developers who understand your solution and your stack, and actively want to contribute.
And for that, you need a good team mentality, easy-to-read code, and a good onboarding. And avoid crunch time as much as possible, especially when a new hire arrive, because you want him to ask dumb questions asap.
[useless personnal anecdote because i feel great about my new workplace removed]
Without knowing the background to that anecdote, the impression I get is less that the tech folks at that company were coddled than that the marketing folks were undervalued. If the marketing folks really are providing value for the company and doing a good job marketing the company, then there's no sense in forcing them to miss lunch. If the marketing folks require so much micromanagement that they can't be trusted to schedule their own lunch breaks they probably aren't contributing significant value to the company anyway, so they should be let go and replaced with a more responsible marketing department.
It takes a lot of different skills to run a company. Even at a tech company, tech isn't the only skill that matters.
I believe that was exactly GP's point—they're just pointing out that the problem with retaining tech workers isn't often that they're treated poorly by their company, even when that might be the problem with retaining many other workers.
>after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling
Why is a single dev able to take down your entire system without intention?
>They can write quicksort but have no idea
So don't use quicksort or identical questions and ask them more.
Your entire anecdote can just as well be held as testament of how a company's process is completely fragile. Which is at least a yellow flag as to what else it is hiding.
You don't need good developers as in top quartile genius ones. Even more, they don't want to work at your bank or web shop. You need good developers, where good means "decent human beings" while being just average ib talent. Those can be found without gigantic effort, I'd say a majority of developers fall in this category. There is only one hard requirement for recruiting such average team. To hire and retain developers who are "decent human beings" the manager/hr should also be good, as in "decent human beings".
Reminds me of the movie "Shaolin Soccer" [1] wherein a martial arts master becomes a soccer coach, and organizes a rag-tag group of misfits into a championship team.
> "Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good.
That's really not true. You don't need to find a Linus or Ken Thompson for that enterprise system. All you need is developers with sufficient maturity to not be distracted by shiny objects, who are proud to build reliable secure systems with the most boring technology applicable (complexity is the enemy of everything, including security, availability and maintainability). These people are easy to find. Yes, you still have to treat them humanely and pay fairly, but finding them is easy.
One factor that may seem to make them difficult to find is the current interviewing landscape. If your hiring process is laser focused on hiring leetcode ninjas, you will staff teams full of leetcode ninjas. I will say the union between the sets (leetcode ninjas) and (maturity to favor stable solutions) isn't super huge.
If for anyone who is doing leetcode hiring (not specifically leetcode, but that mindset) and finding hiring competent people difficult, I can suggest to change your hiring practices and your world will change dramatically.
(Or don't, leaving even more competent developers for me to find even easier.)
There are plenty of highly paid engineers who couldn’t build a decent product given all the coffee in Shoreditch.
As a non-tech person, how do I know to whom I should give all this money? Maybe a hands-off CTO or a hands-on architect cum engineering manager? Or a product person? Or maybe a skilled UX designer? Or a good infrastructure person? Or a DBA, and in which database? Or should I lower the money and get cheaper people in all those roles? Or maybe outsource the whole thing to an agency?
There are plenty of stories of companies who have hired all the above on good money and built an over-engineered, unmaintainable mess that solved zero real world problems.
I would argue that instead of money, you should build it with patience. Hire slowly. Solve one small problem at a time.
If you are a decision maker, especially a CTO, you should be able to know who to give all the money.
True, there are too many people making the wrong technical decisions and by this increasing the complexity of a project easily by 10x or more.
But, to answer your question, if someone doesn’t know, (s)he’s actually simply not in the right position.
When it comes to over-engineering and solving zero real-world problems, that's mostly a company, management and/or investor problem. There's many startups out there where the primary goal is not to solve a business problem profitably but to build a complex engineering playground so they can be part of the "cool kids" club and justify the next VC round.
This translates to hiring - if your job spec is nothing but buzzwords you'll attract the kind of people that "engineer" for engineering's sake and resume value as opposed to solving your business problem (hell, does the job spec even include the actual business problem you're solving beyond vague platitudes about changing the world and boasting about their VC funding?).
Salaries need to reflect it too - if you pay too low, the only people that can afford to work for you are those that do so for the resume value rather than the money or the fun of playing in an engineering playground and potentially becoming its lead - with again zero concern as to whether they're solving the business problem. The kind of engineer you'd actually want usually already makes good money and no longer needs the resume value nor can be bothered to over-engineer.
Even as a contractor I've had plenty of leads where it became clear they weren't looking for an efficient solution to their business problem but an over-engineered mess to expand their engineering playground and my counterpoints fell on deaf ears.
And/or find a developer who makes your other developers better. I've been on many teams now where basic principles of establishing positive team dynamics are ignored so that people can gratify their insatiable egos.
I think the low-code app market has largely fizzled but the low-code data integration market is red hot. Building ETL/ELT and the like is now very much automated with platforms like fivetran. Things that used to require a date engineer are now routinely being done by analysts in much less time.
While there is a correlation to pay, I'd say it's more true to say it's more about hiring for that mindset, and cultivating a culture that understand quick hacks are the slowest/most expensive way.
You can pay more for crap engineers if you dont know what you're looking for.
The cost isn’t in dollars. It’s in energy and intent. That’s the cost they won’t spend until they’re in exquisite pain.
As someone else said, the other company will never care as much as you do. They have a different intent than you do, and making you think there’s common ground is part of how they achieve theirs.
Our team has built a low-code solution to build simple web views and help lower the barriers to making changes. So far it has not saved us any time and arguably has made things worse. The requirements coming in are complex, so instead of building the views in a comfortable environment (our IDE) we are building the same amount of complexity in an environment with rough edges (our LC/NC tool). In my opinion we have misidentified the bottleneck. In reality the time sink is getting clarity on the requirements and understanding the interactions of the components on the page. Whether that page is made in an IDE or in our tool is largely irrelevant.
> In reality the time sink is getting clarity on the requirements and understanding the interactions of the components on the page.
This is the core issue with any sort of complex system. Absolutely nothing matters when the customer is non-responsive with requirements or is not providing enough feedback on prior iterations.
Code vs no-code has absolutely no bearing on this part of the equation.
I do think there is value in low-code or scripted/DSL solutions, but it has to be a very intentional strategy that isn't simply leaning on "configurable == done faster".
"Configurable" is a manager-trap, just like low code. If something's configurable, you now need to forever test all the potential configurations, which always seems to become a combinatorial explosion of tests.
I see this almost every day. A low-code/no-code platform configuration change rolls through the testing lifecycle of straight up code. All the advantages of a low-code/no-code platform fly out the window because the time from feature request to prod is the same as if it were developed from code.
A huge part of my job as a developer is organizing the business person’s thoughts for them, and filling in the non-happy-path 80% of the app that they don’t care about, but their users do.
And doing all that in a coherent way that’s ruthless about maintaining simplicity for as long as possible, including pushing back on business ideas that add marginal benefit but mushroom the complexity of the app.
I've had some bubbling thoughts about no-code that I think just congealed:
No-code is subject to simplicity vs easiness just like code is (https://www.infoq.com/presentations/Simple-Made-Easy/). No-code tools tend to put a huge focus on doing one or both of these things. They're core value-props. But I think the question of whether or not a tool gives you sustainable value comes down to the simplicity axis (vs just making it easier to add more complexity)
A no-code tool that's easier but more complex than the equivalent code solution is probably going to be a net-loss, at least in the long run. Whereas a no-code tool that helps keep things simple by presenting a narrow, focused representation of a system (instead of general-purpose code) can be beneficial.
In a way, no-code can be thought of as a(n invisible) DSL + a GUI
The issue with low code tools is that they typically solve the easy problem.
1.
What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way.
2.
Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers.
Guess what. Software engineers do not just code. They know how to build stuff, which includes a huge amount of knowledge of how to construct maintainable and reliable systems. Put non-engineers on the problem and you will get an unmaintainable mess that is going to be failing a lot.
3.
You try to string your system from a bunch of low-code tools. You quickly integrated a dozen different online tools. Now you find out nobody can understand what is going on. If you hire a person, they will spend a huge amount of time learning all of those tools.
If you build an application let's say in Java, it is much easier to get around the system and understand how it works. If you can read and understand one module, you can pretty much read and understand all of them. But with low code tools strung together there is pretty much new problem, new language, new paradigm for every of those tools.
4.
Part of software development is ability to modify things in a safe way. Having test environment, code versioning, integration and deployment pipelines, etc. Having practices around building stuff. Almost no low-code tools respect any of it. At best you can build your own custom solution for each one but forget trying to prepare v2 of your system and deploy it in any organised way. Your production usually becomes your test environment and your deployments will typically result in some minor drama.
**
I get the appeal of low/no code tools. It is super fun to get something working very quickly with no resources. If you have a simple problem that matches the tool perfectly and you will never want to make it much more complicated -- it might even be the best solution for you.
The issue is that management wants more and you will have to field requests for new functionality and requirements. And you will quickly find adding those will start taking exponentially more effort while you are necessarily spending time talking to your sales reps trying to figure out if/when they can provide the functionality. All this while you have trouble hiring and onboarding people to maintain it because there is just so much magic that only your initial staff is only ever able to understand what is going on.
> What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way.
The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done.
It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have.
An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides.
> Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers.
Or you can cheap out on engineers, because they don't have to code, just use a GUI (which must be easy, it's just point-and-click right? /s) and don't realize that, to solve any problems except the most stereotyped happy-path examples, you need more expertise because now you're actively going against the grain. This isn't as bad in Talend as it is in other things I've worked with, but even in Talend once you start writing actual Java in the components you need to worry about scoping rules because your Java code is just dumped into the middle of a great big method written by Talend itself and the Java compiler isn't in on the gag.
Non engineers know nothing about big o notation or tight coupling. Every time I've seen no-code solutions created by non-engineers it's been O(n^4) monstrosity or worse that's so tightly coupled with it's dependencies that it's a fragile nightmare to keep running.
No-code doesn't mean no code, it just means your code is hidden. Engineering is a skill set and it doesn't start and end with writing code.
I always give the example of my first .NET program (2003? Forgive me if I forget some of the names of things). It was a report page for showing some counts of a field in a file. I build an aspx page and put the asp:Table on it and set the DataSource and in no time I had the list. Then we had to add the total. This required adding a Footer control and some custom code - no problem. Next we had a requirement to add a sub total throughout. This was impossible. So I had to completely throw out everything I'd done and re-write it.
It creates work for already-overworked IT departments.
Think about the sales pitch of low code: Now your marketers and business people can put together solutions to automate business processes, without writing a single line of code (or while writing very few lines of code)!
Except yeah, weeks or months in, those solutions have to be maintained as the business shifts. Sales, marketing, and executives have better things to do than maintain a bunch of instructions for the computer. How will we handle this? Oh, I know! Let's throw it over the wall to the people who specialize in this sort of thing: the software engineers! I'm sure they won't mind prioritizing maintaining the automation we built in $LOW_CODE_PLATFORM over the backlog of other things they have to do.
What are you asking? Where are the debugging tools? Low-code is supposed to have no bugs, what do you need debugging tools for?
Version control? Pffffffff.
Oh, and while you're at it could you integrate the $LOW_CODE_PLATFORM stuff with our mainframe? The source of all truth for customer records is still in the mainframe and--you need to write an extension module to do that? In Java?
One advantage with low/no code I have seen be successful, is allowing non IT teams to do the work themselves therefore reducing the load on IT teams. Notice I said reducing as oversight and training is still required.
It also helps the other teams understand the complexity of there problems (sometimes), and helps IT teams understand the use-case or idea.
I have seen project lead times reduce from month's to days.
All said and done though technical oversight and management is still required.
Have you lived with it over longer period of time?
What happens when stuff evolves and becomes integrated?
I’ve, several times, seen the result of tangled lc/nc stuff gone production critical and… it becomes an unmaintainable mess that no one wants to touch. This becomes a massive roadblock for agility and change down the line.
A simple, discrete, crud app that could have been an xls - sure. Great for PoC and demos; horrible in a live business setting. IME.
Lots of code gets rewritten as it evolves. Even the best developer can't predict the future. And very few can write code so fluid that it adapts to future use.
Also, there are apps that are useful but don't need to be used enterprise wide. No code will change the work environment similar to the way the the spreadsheet changed it.
The problem with software is infinitely larger when rewriting, refactoring and maintaining ”not code”.
I’m in such a situation as we speak, and I’ve worked with low/no code workflow tools for more than a decade.
I’ve been part in building two: one BPM(N) workflow based and one graph-based data-modeling, form-building, event-sourced nightmare (like Alan or structr [1], both probably 10 years old by now, btw) - it goes for a great sales pitch but never touches on the finer points of maintaining and iterating on systems over time; a.k.a ownership!
Coding is usually not the issue, especially in business settings. Rather it’s about accumulating domain knowledge and expertise and figuring out boundaries.
It’s perhaps even more about owning the end results over time.
There’s a sort of quasi-competency built up around tools like this - you still need to understand how to build and govern systems, which is the hard part.
You end up with non-system thinkers that can build opaque stuff in a DSL. This ends badly.
Yeah, I’ve been around. Also blockchain will change everything. ;)
> One advantage with low/no code I have seen be successful, is allowing non IT teams to do the work themselves therefore reducing the load on IT teams.
I'm increasingly beginning to question how this is even an advantage. If your IT team is overloaded... hire more and pay them better.
Another way of saying "allowing non IT teams to do the work themselves" is "taking a specialized job that can be efficiently done by a dedicated professional, splitting it into thousand pieces, and distributing those pieces evenly to everyone". Sure, it's nice that a marketing manager can no-code some automation without having to bother an overworked IT person, but now no-coding that automation becomes yet another little bullshit task that distracts them from their core competency, i.e. marketinging.
This is one of those trends that feel beneficial on the surface, but less so if you look closely, at least in job context. The OG one are office suites - particularly word processors, spreadsheets and calendars. Yes, it's nice that I can write my own reports, tally stats on my own, or manage my own meetings. It's less nice that I have to do it all the time, where in the past, there were people hired specifically to handle this job for everyone else. How many highly-paid software engineers are being distracted and waste their time on this, only so that corporate can save on hiring lower-paid secretaries?
I don't think it even adds up economically, but the trick is, once you eliminate a job with software by outsourcing it bit by bit on everyone else, even though it's now much more expensive, it disappears from the company books. Not having to pay extra salaries is legible. Overall unexplained productivity drop is not.
The company IT department has been disappearing from enterprises for years. Companies use SaaS apps and outsource many of the other functions so no code is just another step towards a no IT department. IT costs are an easy target for cuts so expect all functions to be reduced or outsource over time.
Agree with this post. Low-code lets a non-engineer build 80% of an app quickly, but then ultimately that last 20% requires engineering work and it ends up taking more total eng/IT time to create something far less maintainable and useful.
I think the best low-code platforms are ones that are ultimately built on top of code (eg Webflow, where the underlying representation is normal HTML/CSS/JS). I wrote a blog post about how I think low-code platforms are broken and how they could be fixed: https://www.airplane.dev/blog/how-to-fix-low-code-with-more-...
I would like to see a general acceptance from people that the thing they think they need can really just be described in a more generic and less "we have unique needs" way, which is often a good chunk of the missing 20%.
But that's a lost cause until there's a meteoric shift in our industry towards standards and modularity, which either will never happen or won't happen in the lifetimes of the current generations.
Low-code tools are typically oriented toward technology rather than information. As such they are analogous to automating buggy-whips instead of improving transportation. Below is an example of what focusing on information can do.
If you allow LLMs (Large Language Models) to directly call out to APIs, like POSIX, Vulkan, Win32, X11, etc. then it may become possible to program things using a "Socratic" method that involves producing no code at all. You simply channel inputs to the LLM, collect API calls from the LLM, and execute the API calls it makes. This will create a feedback loop that'll eliminate the need to produce code at all. Code can then be produced selectively as an optimisation, like what we call "compilation" today.
Of course, it's currently unreliable and slow, but the trend is a fast one.
Additionally, it might be given a memory store it could read from and write to -- and a StackOverflow-like network to curate advice from other AIs like itself.
A half-way version of this might soon start to exist.
The problem with these generative systems is that they're synthesizing existing code and their output isnt therefore always valid. Ie., they arent programming (which involves following discrete constraints of the language).
They are, therefore, largely tools for power-users. You need to understand why codepiolt/etc. is suggesting a completion before its actually useful.
If you prefer: Intelligence is knowing what question to ask, and knowing how to validate the answer.
Oh god no. No please don't let "power-users" anywhere near a Low Code framework. It doesn't take long for them to fuck up and go ask a real developer what is wrong. I've seen things...
> It doesn't take long for them to fuck up and go ask a real developer what is wrong. I've seen things...
Worse is when it doesn’t take them long to fuck up, but it does take them (or, often, other people in the org, possibly after they’ve left) long to bring in a dev...
At that point, the LLM is just a compiler, and your prompt becomes the "code".
I can easily imagine something like this taking off. After all it would be a giant step towards two things we have been trying since the 60s: a programming language intuitive enough that business people can use it, and a declarative approach where you describe what you want to achieve, not which steps to take.
That said, if all the current prompt engineering is anything to go by, using such an approach effectively might still require a lot of skill. But the barrier to entry would be a lot lower, and for some classes of problems it might be much more efficient in terms of programmer time.
My low-code exposure is mostly limited to Microsoft SSIS, but my experience is that the only people skilled enough to build reliable and maintainable packages were already good coders.
QA took a hit because developers saw how unmaintainable the test code was. Operations writes code that’s almost as bad as what QA writes. Non coders writing code always makes a bigger mess for the actual coders.
friends, lets not berate, belittle, or subjugate each other and instead share the practical experience. Its a hard sell - i guess my so is right: i should start a blog. downvote this old timer's ramblings - sometimes we need to spell out what we resist
I am currently working with low/no code to build an application that will form the backbone of the core domain at a F500 company. The application will eventually host 1000's of users across the world. The main takeaway is that there is a world of difference between work produced by someone with actual real world coding experience and those that just learned on the no code platform. Real engineers are able to use the platform as essentially just another programming language while the non engineers build horribly inefficient outputs. When you speak to the non engineers its clear they have no concept of what it takes to make a system work and scale or anything that a software engineer would consider vital to a robust application, they just connect component A to component B. No code is just a tool, the quality of the builders controls the quality of the product. I will add though that there are definite gotchas to no code environments that can spell disaster to the end result. I have found things like hidden settings in the platform that control memory management, state, etc. Pretty frustrating to realize suddenly your application cannot scale and its because of something hidden in an environment level setting somewhere that no one even told you existed.
Were you in the room when it was sold to you? Curious if these things are sold as “more convenient tool for your existing programmers” or “you won’t have to hire so many programmers.”
Circa 1997 I started work in web development. It was a wild and wooly time. We effectively produced a time & attendance system for a major university using ASP. Not ASP.Net, ASP. And frames, lotsa frames. Fun times, but... we did not have any of the following:
* An IDE that knew anything; I literally wrote in Notepad
* Backup/restore procedures to speak of.
* Defined release/rollback procedures.
* Any monitoring beyond "walk to the server and look at the CPU monitor".
* Source control.
* 3rd party libraries.
* Cloud deployment complexities; one server, one deployment.
* A DBA or anything resembling one.
* Automated testing.
* A (solid) distinction between dev & production
* QA
* Cloud/reliable 3rd party logging.
* PII or other info control issues
* Security/compliance software, needs, etc.
* Documentation requirements
and I'm honestly probably forgetting a few things I could add in that I now consider a bare minimum for a production professional deployment.
Many of these are only partially automatable by some service. Some are not automatable at all. Some you can automate to your heart's content but it won't matter because the user has an irreducible responsibility to use them correctly themselves, no matter how much you simplify it, like source control or writing documentation.
Last week one of my tasks was to dive into codebases that were 17 years old, and hadn't been touched in 12, and figure out what was going on and how to fix a new issue. At that point in time this company was a startup and certainly wasn't following 2022 best practices by any means, but at least they had source control, the source code was checked in, and it still built. (Very simple C programs, fortunately, single files with no external dependencies.) On the one hand, enough good dev practices that I could still pick up the pieces even if they are sadly deficient by modern standards, on the other hand, still more good dev practices than you can ask for from a non-programmer.
What does the equivalent of this look like for this "no-code" stuff? Who is going to poke through a big pile of stuff, where even if it is nominally "source controlled" or has a "managed DB" was not source-controlled well and the "managed DB" amounts to "well, when they guy who didn't understand DBs at all and was in fact aggressively told he shouldn't have to because this software Does It All decided he needed to add a column, it just went ahead and did it" and so and and so forth, is now a 10-20 year old pile of vendor-specific "no code"?
The intrinsic contradiction of the "no code" stuff is that we programmers do not have all this source control and testing platforms and QA procedures and deployment and rollback procedures and all of that other stuff because we are sticks in the mud who love process. We have all these things because we've learned the hard way they are necessary. I use them even on my projects where I have a single developer for maybe a month! And that's a tiny project, and they still save my bacon over and over. I look at my 1997 list in 2022 and both despair and laugh at what passed for a production deployment back then. For a modestly critical system for what is basically a ~50,000 person company. No-code trades short-term easier for medium- and long-term harder.
I can't even imagine what legacy no-code will look like and what a nightmare it will be. Without sarcasm, I'm sure it will make the 20-year-old, umpty thousand line Perl code base that I was also in last week look like paradise.
No-code is great for exploration of problems, and for all I may seem to be slagging on it here, I believe it has a place and it is worth exploring. But it is sheer foolishness to think it can "solve overworked IT department"'s problems. A no-code solution would ...
Thanks for this great piece of text. It triggered some memories. These tools exist for a reason. Let’s hope we don’t have to use your highway construction analogy too often :-)
There was no unit testing, no valgrind or anything like that, no documentation... I mean, honestly, other than the fact it compiled, worked, and was broadly speaking safe to use by virtue of not being on the network (it's a batch conversion process with the input being fairly rigidly constrained, no external user input basically), it didn't have much of anything else going for it. I think what comments it had in it may even have been wrong; I didn't stare at it enough to be sure. My intuition says it should have been running about 10 times faster than it was, too. Not sure if I'm just too used to multithreaded performance nowadays, if there was actually something wrong in there, or if I was wrong for some reason.
This sounds like either a Salesforce project or the Microsoft equivalent (i forget what it's called). I do a lot of Salesforce, the best Salesforce people for configuration and customization are seasoned software developers.
Power Apps: A raw app is easy to get running but a nice app that does what I want is hacky.
Pentaho Data Integration: Super easy to use and maintain.
MS Access: Fast development and you can do actual programming if need be.
Among these tools, I just don't see a need for power apps and desktop apps written in MS Access are not something people are looking for any more. PDI on the other hand makes it easy to ETL data and has saved me countless hours over the years.
These are code generators right? Right? With the usual code generation issues with debugging, verification, or long term maintenance?
Or they are workflow tools, sold with simple graphical demos of easy state machines / START -> box -> box -> box -> DONE flows, but when the rubber hits the road you encounter branching, loops, retries, subroutines, error codes, suspended/paused flows, state management, and full on turing machine processing.
Or they are AI tools, and you are relying on statistical probabilities that the code does what you want to, and statistical probabilities that the AI isn't producing the answer that looks right and the one you want versus the actual answer?
Or you are writing so much testing/quality control /verification that you might as well have coded in the first place?
Finally, you are invariably dealing with a vendor, and massive massive massive vendor lockin. Have fun when Oracle acquires them, triples the price, and audits you every other year.
LC may be a way to quickly get to the happy path but for reasons deep in business processes and underlying technology the happy path is just one of billions of possible paths most of them leading to a not so happy result. Dealing with exception and error situations in a sane manner is hard and I don't see it getting easier. Certainly not by adding a few abstraction layers.
I see the appeal of low/no code, but have yet to find a platform that I think does it well. The sell is that "business users" can write their own apps/sites/etc. That ends up not materializing - business users don't want to or can't. So they get a dev to use the tool. So now, a dev is stuck using a tool that feels like death by a thousand clicks and locks the org into a subscription and ecosystem.
I do feel like there is a solution here. On the dev side, what should be simple business apps written in code are too complex, and have too much cruft. Upgrading frameworks is a hassle. It should be easier.
I feel like a popular really well done open source AI code generation tool could solve this and is waiting to be written.
Good low/no-code solutions do a great job of aiding discoverability and cutting the need to grapple with a language's syntax. Unfortunately, while this is a roadblock for many, the challenge is more fundamental. What makes a good programmer isn't knowledge of a language, it's the ability to translate a vague description of objectives into a precise specification of a solution (especially when the vague description is under-specified).
This is one of the biggest challenges I see people struggling with as they learn programming: Cutting out the implicit assumptions that humans make every time they communicate with each other, and interactively working to understand *exactly* what needs to happen and why.
Interactive AIs (e.g., Copilot, ChatGPT), in principle, could address the specification problem. Unfortunately, in their current state, they have no concept of what they don't know or understand. Gaps in the specification are filled in with assumptions, and one of the main criticisms of these tools at the moment is that they have no way to reason about how appropriate these assumptions are. It seems likely that we'll eventually reach a point where simple AIs can replace devs for the relatively simple tasks that low/no-code solutions target. However, for this to happen, (i) the AI would need the ability to reason about uncertainty/incompleteness in the prompt it's given, and (ii) the AI would need to be able to interactively work with the user to refine the specification.
I’ve had no issues with power automate and logic apps the few times I’ve had to use them. The last time I called voice to text and sentiment analysis APIs triggered on receiving an email with an audio attachment. It would reply to the email with the transcription and sentiment details. Was stupid easy and took about an hour to build and test and it just worked and has worked without any issues for the last three years. I have no idea how well most business users could work their way through something like that though.
ELI5: low-code/no-code is nothing new, it was with us for longer than you can imagine, so why do we expect that nowadays it's gotten so much better that it can replace normal programming?
For me it sounds like another Web3AIBlockchainVRMeta fad, like those trends in history: romanticism, baroque, enlightenment, etc.
Asked and answered. But someone is selling the trend and making money on it. Whether it’s a good long term solution to anything is rather inconsequential to them.
That said, as development tool chains grow in options and complexity , I do see these things as being a bridge for some people to get their feet wet. Self taught devs can start here and then code later when needed. But that’s just a theoretical use case/market void that may not really exist.
Low code/no code == low quality / no quality code.
You produce simple hello world or CRUD type stuff (but these should be replaced by SaaS, like google sheets/google forms/airtable/etc).
Anything more complicated - you are looking at mountain of glue scripting to stich together different parts and maintaining that frankenstein of code
Low code like powerapps however solve a myriad of problems for regular users but I agree with the post.
The one area I find a bit concerning is governance/management around the data and permissions low-code apps ask. In a powerapps context for example, the app might ask permissions to read all your onedrive, sharepoint or email and it may even have a good reason to do so but now that means if the regular user who composed it gets compromised, threat actors get all that data from the user's of the powerapp.
I am guessing other low code frameworks also work with some business or user data. Low code means easy to compose and less low level coding error related vulns but you can still have a vulnerable low code app.
211 comments
[ 3.8 ms ] story [ 243 ms ] threadNo code won't fill all needs but they have a place in business.
> Everyone is talking about chatgpt and code generation this week. I think the code generated with chatgpt might be 90% accurate but how confident would you be to deploy that in production.
I haven't been paying close attention, but all the code I've seen it generate is also very simple -- like the kind of stuff someone could write after taking an intro programming class, prompted by a pretty detailed specification.
Modern-day software engineers basically write detailed specifications, they don't translate specifications into "code." Whether you're writing "AI prompts" or Python, it'll still be software engineering. Though my gut feel is software engineering by prompts will feel like typing with a wet noodle to hit the keys.
[1] https://towardsdatascience.com/i-used-chatgpt-to-create-an-e...
Software Engineers will have their place but no code and AI is aiming for the masses.
I actually think low-code will see a resurgence serving "almost technical" people such as tech business analysts, and also, drum roll... programmers. There is a current generation of maturing low-code tools (ex: Retool, PowerApps, Plasmic, Builder.io) which allow tech people to combine low-code and code as needed and which programmers may actually find attractive.
As for AI (ex: GPT), the main output it provides is code. It's nearly impossible to operate it at present for code-generation tasks without knowing how to code. Yes I think it's inevitable we will see a tool that blends current low-code graphical programming with NLP inputs. But it sounds very complex to make and I think it is likely to face the same base problems that low-code has.
Also, a thing people not considering with AI-assisted coding is that if it really makes programmers more productive, there'll be more chances to tend to more projects.
The second a difficult bug arises in your low-code (or, now, GPT-generated) solution, good luck.
No, I believe the cloud stuff has evolved in a way that is just strange. I know I'm not stupid, and I look at this stuff with suspicion. This is why I'm going vertical by owning my entire stack (except Amazon S3 because it is awesome...)
I wish it was cheaper, but I can leverage it well.
Nobody would design it like that from scratch but having only already existing stuff to build on makes the end result more complex that the problem it solves requires
And have a compelling product ...
You'd think the success of his model would be used elsewhere to reduce employer costs and increase retention (no SWE has left his org in 4 years). Instead other petty executives get pissy and poison the well.
Something is extremely off with modern corporate America.
But even a pretty low level developer is going to end up making important business decisions just incidentally as part of their job, because it's hard to specify out every little decision that could impact the business without basically doing the dev's job for them.
Businesses can embrace that or they can ignore it at their peril.
That's how it's done at all the US software companies I've worked at, including Microsoft and some startups.
My current company does has done away with job-titles entirely and we make up whatever we want on our business-cards (within reason).
Everybody organizes people, decide how work should be done, and has to make a lot of little decisions that nobody could anticipate. Not with the same leverage as developers, but with important consequences too. Somehow, management experts can't accept this.
We establish a difference between jobs where that training is relatively short (and thus we can expect it to happen on-site by the company who can hire people from other positions and have them do the new job) and the jobs where that training takes many years and thus requires significant pre-commitment and long-term planning to ensure that they can be filled.
For the purposes of crude statistics we pick an arbitrary line and label the jobs with <1 year of job-specific training required (starting from generic knowledge e.g. highschool or a degree in some other field) as "unskilled" and >1 year job-specific training required as "skilled"; but the key point is that there is a substantial qualitative difference between roles where you can "swap" people from one industry to another, and roles where that doesn't make sense at scale - while some individuals do switch high-investment careers, you're not going to solve a pandemic-prelate doctor shortage by re-purposing excess lawyers, but in that same pandemic you can solve a delivery driver shortage by re-purposing excess cashiers. Similarly in IT, the jobs which can be done by putting someone through an x-week boot camp do need different treatment from managers and policy-makers than the tech jobs which do require much more training and/or experience.
Bad managers thinks a managers role is all about making decisions. Great managers knows it's about enabling employees: great managers act more like secretaries, making sure everybody knows everything they need.
When a manager can communicate what is going on and what the strategy is, most decisions become obvious and this results in everybody agreeing to what needs to be done.
That’s because large corporations are typically run like communist states, where the workers have little say in their own work, and tyrannical unelected leadership sets up hierarchies that reward political infighting to build power.
Why don’t corporations try democracy and bottom-up decision-making? Is corporate capitalism incompatible with democracy?
You're describing capitalism, actually.
> try democracy and bottom-up decision-making
Those are called worker co-ops. They're very socialistic. And democratic. It's quite possible for them to be profitable, too.
When the new CEO was brought on they started to listen to the junior executives. They poison the well by stating things like how what he is doing isn't necessary or slowing down their own goals.
Just humans being humans. As a result he will likely leave in <2 years. I don't doubt that his old org will falter extremely fast.
It seems like well run orgs with less people are highly susceptible to quick change than large useless behemoths. Seems paradoxical, but a common fate at many companies/orgs.
"Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good. The paying them a good salary and treating them well, companies are right onboard with in my experience. The tech department has better working conditions that most other departments. I worked at one company and one of the marketing teams once had to leave a resturant before eating because their lunch time ran out. So they paid for their food and left without it. All the techies just looked on in shock. We came and went as we wanted.
But the thing of finding good developers is hard. Even if you target just the folks in the top 50% of the bell curve, it's still going to be hard. And in my experience you get a few lower quality developers in and the next minute you've got someone saying their AWS lambda solutiuon can scale to any level 10 minutes after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling... I swear to god, even the non-technical folk knew the guy was talking nonsense. And the thing is, these people can and will pass your tech tests because honestly tech tests aren't really good at showing you how good a developer is actually understanding things. They can write quicksort but have no idea, how to figure out the best way to scale a data export feature that is crashing because of memory limits.
And the thing really with no-code, you encounter a bug, you're possibly dependent on a third party to fix the bug. Not a good place to be in because they never care as much as you do.
How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?
If you honestly think being asked those 2 simple questions is not being treated well. You're going to have a hard life.
IMO this is absolutely crucial to understand about our industry, for programmers too, not just IT.
We're paid well because they can't avoid paying us well. But they don't want to let us in The Club of the actual professional or upper-middle class, in terms of perks and status (and, actually, pay in most of the industry, even in the US, doesn't quite rise to that level—$200k+ for mid-career-or-earlier isn't what most programmers see).
Frequent monitoring and things like open floorplan offices are part of that. High-status gets very little monitoring, and an office. There are tons of little things like this.
I think it may also be a minor reason our interviews are so god-awful (but I think the main reason is the huge players trying to reduce turnover to suppress the rate of wage increases).
When companies want a fully algorithmic way to filter for signal, it’s not because we think it’s a great process, but because it’s one of the only viable processes.
PLEASE explain to me what value leetcode-type questions provide over what good of a software engineer someone is!
Here's simple task that I ask on interviews: write JavaScript function which works like setTimeout and uses setTimeout internally but provides a Promise result so it can be awaited. Very few people can write that kind of code. They actually have no idea what Promise is. They want to get in frontend position. How can you write frontend code if you have no idea what Promise is.
Would that piece of information be helpful to you as you consider which candidates to invite to the first round of interviews? That is why companies do it.
A candidate who got 2 or 3 solved in 90 minutes is very likely to do much better on the rest of the interview and on the job than someone who couldn't solve any.
(I think a lot of people who can write code have a difficult time imagining just how many people both can't write code and apply for seemingly every posted SWE job listing.)
Haha. Hiring people is a job in and of itself. It needs a good eye for detail and intuition.
People are weird. Some days they write great code and hardly any serious bugs. Other days they need to look up a for-loop on MDN.
Get some perspective ffs. This is the easiest, cushiest job I've ever had, and the only one where people with masters degrees often consider me their peer despite my 11th grade education.
Stop whining and join a union or something seriously. These are all minor and solvable problems.
Please get some perspective not everyone is in your situation.
Many IT jobs are paid hourly, don’t get health insurance, and some even get paid minimum wage. That said, I have had plenty of people describe their retail jobs as cushy because it’s low physical labor, inside with AC, and they don’t have to think.
Long hours and little respect probably will vary from one employer to the next. However, I've been working as a developer for about ~10 years - most of it with a mid-size insurance company but the last couple with a large bank. I work longer hours than most of my colleagues, but I've rarely put in more than 50 hours in a week, and my average is probably closer to 45. And my non-engineering colleagues have always treated my fellow engineers and me with respect and an appreciation for the difficulty of what we do. If anything, they've usually been a bit too deferential.
YMMV, but I think our profession is probably among the best in the world for workers. If my child were about to enter the working world and had the ability + interest, I'd absolutely recommend this as a career.
However, being on call is representative of something. Your electric company has linemen ready to respond at 2AM because they provide a service which needs to be available 24/7. However, good luck trying to contact your dermatologist, accountant, physical trainer etc at 2AM.
For all practical purposes, above a certain level of management, you are implicitly on call all the time. However, the bar to clear to engage you gets higher the further up the leadership layers you go. A manager of a handful of teams comprising about 100 staff gets engaged for less serious fires than the CEO, but both are "on call". It might take the board of directors chartering a helicopter to get to the CEO's fly fishing cabin during the CEO's vacation if a situation warranting such presents itself, but the CEO is absolutely on call 24x7x365.
The complexity of what engages the on call person I suspect is what connotes status. Called for clearing out disk space: low status. Called for application outage that has stumped multiple technical teams: higher status. Called for a production outage impacting the next day's C-level reports that requires engaging other management: higher status. Called for heading off a shareholder proxy battle: even higher status.
Note here complexity doesn't solely reside in the technical realm, but frequently is rather a blend of technical factors, social factors, and quickly making impactful decisions in low-information situations.
I can't wait for low-code to get good. It's going to throw back in real time the obliqueness of the request:
"Validating most likely candidate solution..."
8 hrs later
"Solution failed to validate ... please try rephrasing request."
It may not be indicative of the industry at large, but most engineers I know get away with this by changing the framing "I'm working on a doc" or "I'm scoping this feature" etc. Obviously this does not work with sufficiently bad management.
Care to outline it for me?
They're even busier in public hosptials btw
I am a disorganized guy who hates authority and interruptions, and even so I have grudgingly come to realize that (strictly) 15-minute morning standups actually do increase my productivity.
What you really want is developers who understand your solution and your stack, and actively want to contribute.
And for that, you need a good team mentality, easy-to-read code, and a good onboarding. And avoid crunch time as much as possible, especially when a new hire arrive, because you want him to ask dumb questions asap.
[useless personnal anecdote because i feel great about my new workplace removed]
It takes a lot of different skills to run a company. Even at a tech company, tech isn't the only skill that matters.
Why is a single dev able to take down your entire system without intention?
>They can write quicksort but have no idea
So don't use quicksort or identical questions and ask them more.
Your entire anecdote can just as well be held as testament of how a company's process is completely fragile. Which is at least a yellow flag as to what else it is hiding.
Software is a team sport.
[1] https://en.wikipedia.org/wiki/Shaolin_Soccer
IT departments love this, because it's not their problem and they don't have to do anything except press reload in the third party's ticketing system.
That's really not true. You don't need to find a Linus or Ken Thompson for that enterprise system. All you need is developers with sufficient maturity to not be distracted by shiny objects, who are proud to build reliable secure systems with the most boring technology applicable (complexity is the enemy of everything, including security, availability and maintainability). These people are easy to find. Yes, you still have to treat them humanely and pay fairly, but finding them is easy.
One factor that may seem to make them difficult to find is the current interviewing landscape. If your hiring process is laser focused on hiring leetcode ninjas, you will staff teams full of leetcode ninjas. I will say the union between the sets (leetcode ninjas) and (maturity to favor stable solutions) isn't super huge.
If for anyone who is doing leetcode hiring (not specifically leetcode, but that mindset) and finding hiring competent people difficult, I can suggest to change your hiring practices and your world will change dramatically.
(Or don't, leaving even more competent developers for me to find even easier.)
There are plenty of highly paid engineers who couldn’t build a decent product given all the coffee in Shoreditch.
As a non-tech person, how do I know to whom I should give all this money? Maybe a hands-off CTO or a hands-on architect cum engineering manager? Or a product person? Or maybe a skilled UX designer? Or a good infrastructure person? Or a DBA, and in which database? Or should I lower the money and get cheaper people in all those roles? Or maybe outsource the whole thing to an agency?
There are plenty of stories of companies who have hired all the above on good money and built an over-engineered, unmaintainable mess that solved zero real world problems.
I would argue that instead of money, you should build it with patience. Hire slowly. Solve one small problem at a time.
This translates to hiring - if your job spec is nothing but buzzwords you'll attract the kind of people that "engineer" for engineering's sake and resume value as opposed to solving your business problem (hell, does the job spec even include the actual business problem you're solving beyond vague platitudes about changing the world and boasting about their VC funding?).
Salaries need to reflect it too - if you pay too low, the only people that can afford to work for you are those that do so for the resume value rather than the money or the fun of playing in an engineering playground and potentially becoming its lead - with again zero concern as to whether they're solving the business problem. The kind of engineer you'd actually want usually already makes good money and no longer needs the resume value nor can be bothered to over-engineer.
Even as a contractor I've had plenty of leads where it became clear they weren't looking for an efficient solution to their business problem but an over-engineered mess to expand their engineering playground and my counterpoints fell on deaf ears.
Too often I've seen companies offshore a project only to require a full rewrite in 6 months because "that wasnt in the spec" during the first version.
Well written software expands your options as it grows, not shrinks them.
You can pay more for crap engineers if you dont know what you're looking for.
As someone else said, the other company will never care as much as you do. They have a different intent than you do, and making you think there’s common ground is part of how they achieve theirs.
This is the core issue with any sort of complex system. Absolutely nothing matters when the customer is non-responsive with requirements or is not providing enough feedback on prior iterations.
Code vs no-code has absolutely no bearing on this part of the equation.
I do think there is value in low-code or scripted/DSL solutions, but it has to be a very intentional strategy that isn't simply leaning on "configurable == done faster".
And doing all that in a coherent way that’s ruthless about maintaining simplicity for as long as possible, including pushing back on business ideas that add marginal benefit but mushroom the complexity of the app.
No-code is subject to simplicity vs easiness just like code is (https://www.infoq.com/presentations/Simple-Made-Easy/). No-code tools tend to put a huge focus on doing one or both of these things. They're core value-props. But I think the question of whether or not a tool gives you sustainable value comes down to the simplicity axis (vs just making it easier to add more complexity)
A no-code tool that's easier but more complex than the equivalent code solution is probably going to be a net-loss, at least in the long run. Whereas a no-code tool that helps keep things simple by presenting a narrow, focused representation of a system (instead of general-purpose code) can be beneficial.
In a way, no-code can be thought of as a(n invisible) DSL + a GUI
1.
What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way.
2.
Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers.
Guess what. Software engineers do not just code. They know how to build stuff, which includes a huge amount of knowledge of how to construct maintainable and reliable systems. Put non-engineers on the problem and you will get an unmaintainable mess that is going to be failing a lot.
3.
You try to string your system from a bunch of low-code tools. You quickly integrated a dozen different online tools. Now you find out nobody can understand what is going on. If you hire a person, they will spend a huge amount of time learning all of those tools.
If you build an application let's say in Java, it is much easier to get around the system and understand how it works. If you can read and understand one module, you can pretty much read and understand all of them. But with low code tools strung together there is pretty much new problem, new language, new paradigm for every of those tools.
4.
Part of software development is ability to modify things in a safe way. Having test environment, code versioning, integration and deployment pipelines, etc. Having practices around building stuff. Almost no low-code tools respect any of it. At best you can build your own custom solution for each one but forget trying to prepare v2 of your system and deploy it in any organised way. Your production usually becomes your test environment and your deployments will typically result in some minor drama.
**
I get the appeal of low/no code tools. It is super fun to get something working very quickly with no resources. If you have a simple problem that matches the tool perfectly and you will never want to make it much more complicated -- it might even be the best solution for you.
The issue is that management wants more and you will have to field requests for new functionality and requirements. And you will quickly find adding those will start taking exponentially more effort while you are necessarily spending time talking to your sales reps trying to figure out if/when they can provide the functionality. All this while you have trouble hiring and onboarding people to maintain it because there is just so much magic that only your initial staff is only ever able to understand what is going on.
I'll repost an old post of mine:
https://news.ycombinator.com/item?id=33703563
The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done.
It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have.
An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides.
> Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers.
Or you can cheap out on engineers, because they don't have to code, just use a GUI (which must be easy, it's just point-and-click right? /s) and don't realize that, to solve any problems except the most stereotyped happy-path examples, you need more expertise because now you're actively going against the grain. This isn't as bad in Talend as it is in other things I've worked with, but even in Talend once you start writing actual Java in the components you need to worry about scoping rules because your Java code is just dumped into the middle of a great big method written by Talend itself and the Java compiler isn't in on the gag.
No-code doesn't mean no code, it just means your code is hidden. Engineering is a skill set and it doesn't start and end with writing code.
Such things make the easy stuff easier and the hard stuff impossible.
As long as that's understood that's fine. If it's not you are in trouble.
Think about the sales pitch of low code: Now your marketers and business people can put together solutions to automate business processes, without writing a single line of code (or while writing very few lines of code)!
Except yeah, weeks or months in, those solutions have to be maintained as the business shifts. Sales, marketing, and executives have better things to do than maintain a bunch of instructions for the computer. How will we handle this? Oh, I know! Let's throw it over the wall to the people who specialize in this sort of thing: the software engineers! I'm sure they won't mind prioritizing maintaining the automation we built in $LOW_CODE_PLATFORM over the backlog of other things they have to do.
What are you asking? Where are the debugging tools? Low-code is supposed to have no bugs, what do you need debugging tools for?
Version control? Pffffffff.
Oh, and while you're at it could you integrate the $LOW_CODE_PLATFORM stuff with our mainframe? The source of all truth for customer records is still in the mainframe and--you need to write an extension module to do that? In Java?
It also helps the other teams understand the complexity of there problems (sometimes), and helps IT teams understand the use-case or idea.
I have seen project lead times reduce from month's to days.
All said and done though technical oversight and management is still required.
What happens when stuff evolves and becomes integrated?
I’ve, several times, seen the result of tangled lc/nc stuff gone production critical and… it becomes an unmaintainable mess that no one wants to touch. This becomes a massive roadblock for agility and change down the line.
A simple, discrete, crud app that could have been an xls - sure. Great for PoC and demos; horrible in a live business setting. IME.
Also, there are apps that are useful but don't need to be used enterprise wide. No code will change the work environment similar to the way the the spreadsheet changed it.
I’m in such a situation as we speak, and I’ve worked with low/no code workflow tools for more than a decade.
I’ve been part in building two: one BPM(N) workflow based and one graph-based data-modeling, form-building, event-sourced nightmare (like Alan or structr [1], both probably 10 years old by now, btw) - it goes for a great sales pitch but never touches on the finer points of maintaining and iterating on systems over time; a.k.a ownership!
Coding is usually not the issue, especially in business settings. Rather it’s about accumulating domain knowledge and expertise and figuring out boundaries.
It’s perhaps even more about owning the end results over time.
There’s a sort of quasi-competency built up around tools like this - you still need to understand how to build and govern systems, which is the hard part.
You end up with non-system thinkers that can build opaque stuff in a DSL. This ends badly.
Yeah, I’ve been around. Also blockchain will change everything. ;)
[0] https://alan-platform.com/
[1] https://structr.com/
1) produces a just wildly, horribly inefficient solution, just doesn’t care about optimization or big-O at all.
2) guides the user through producing some reasonably sane design docs that describe what they are trying to accomplish
Then you’d pass those docs and the toy implementation along to a programmer
I'm increasingly beginning to question how this is even an advantage. If your IT team is overloaded... hire more and pay them better.
Another way of saying "allowing non IT teams to do the work themselves" is "taking a specialized job that can be efficiently done by a dedicated professional, splitting it into thousand pieces, and distributing those pieces evenly to everyone". Sure, it's nice that a marketing manager can no-code some automation without having to bother an overworked IT person, but now no-coding that automation becomes yet another little bullshit task that distracts them from their core competency, i.e. marketinging.
This is one of those trends that feel beneficial on the surface, but less so if you look closely, at least in job context. The OG one are office suites - particularly word processors, spreadsheets and calendars. Yes, it's nice that I can write my own reports, tally stats on my own, or manage my own meetings. It's less nice that I have to do it all the time, where in the past, there were people hired specifically to handle this job for everyone else. How many highly-paid software engineers are being distracted and waste their time on this, only so that corporate can save on hiring lower-paid secretaries?
I don't think it even adds up economically, but the trick is, once you eliminate a job with software by outsourcing it bit by bit on everyone else, even though it's now much more expensive, it disappears from the company books. Not having to pay extra salaries is legible. Overall unexplained productivity drop is not.
I think the best low-code platforms are ones that are ultimately built on top of code (eg Webflow, where the underlying representation is normal HTML/CSS/JS). I wrote a blog post about how I think low-code platforms are broken and how they could be fixed: https://www.airplane.dev/blog/how-to-fix-low-code-with-more-...
But that's a lost cause until there's a meteoric shift in our industry towards standards and modularity, which either will never happen or won't happen in the lifetimes of the current generations.
IKEA’s knowledge graph and why it has three layers: https://news.ycombinator.com/item?id=32749633
Of course, it's currently unreliable and slow, but the trend is a fast one.
Additionally, it might be given a memory store it could read from and write to -- and a StackOverflow-like network to curate advice from other AIs like itself.
A half-way version of this might soon start to exist.
"I told it to delete users from my contact list, not just delete them from system!"
They are, therefore, largely tools for power-users. You need to understand why codepiolt/etc. is suggesting a completion before its actually useful.
If you prefer: Intelligence is knowing what question to ask, and knowing how to validate the answer.
Worse is when it doesn’t take them long to fuck up, but it does take them (or, often, other people in the org, possibly after they’ve left) long to bring in a dev...
I’ve seen things, too...
Actual programmers have this problem too, though they often use non-AI tooling to catch and prompt them to correct invalid code.
No reason a system using an LLM for code generation couldn't do that, too.
Anticipating the “but even if it is valid it won’t always be correct” followup: well, valid human-written code also often has bugs.
I can easily imagine something like this taking off. After all it would be a giant step towards two things we have been trying since the 60s: a programming language intuitive enough that business people can use it, and a declarative approach where you describe what you want to achieve, not which steps to take.
That said, if all the current prompt engineering is anything to go by, using such an approach effectively might still require a lot of skill. But the barrier to entry would be a lot lower, and for some classes of problems it might be much more efficient in terms of programmer time.
What could possibly go wrong?
I know! Hook it up to manage people's retirement savings / 401(k) for pennies on the dollar compared to traditional portfolio managers.
Many of these are only partially automatable by some service. Some are not automatable at all. Some you can automate to your heart's content but it won't matter because the user has an irreducible responsibility to use them correctly themselves, no matter how much you simplify it, like source control or writing documentation.
Last week one of my tasks was to dive into codebases that were 17 years old, and hadn't been touched in 12, and figure out what was going on and how to fix a new issue. At that point in time this company was a startup and certainly wasn't following 2022 best practices by any means, but at least they had source control, the source code was checked in, and it still built. (Very simple C programs, fortunately, single files with no external dependencies.) On the one hand, enough good dev practices that I could still pick up the pieces even if they are sadly deficient by modern standards, on the other hand, still more good dev practices than you can ask for from a non-programmer.
What does the equivalent of this look like for this "no-code" stuff? Who is going to poke through a big pile of stuff, where even if it is nominally "source controlled" or has a "managed DB" was not source-controlled well and the "managed DB" amounts to "well, when they guy who didn't understand DBs at all and was in fact aggressively told he shouldn't have to because this software Does It All decided he needed to add a column, it just went ahead and did it" and so and and so forth, is now a 10-20 year old pile of vendor-specific "no code"?
The intrinsic contradiction of the "no code" stuff is that we programmers do not have all this source control and testing platforms and QA procedures and deployment and rollback procedures and all of that other stuff because we are sticks in the mud who love process. We have all these things because we've learned the hard way they are necessary. I use them even on my projects where I have a single developer for maybe a month! And that's a tiny project, and they still save my bacon over and over. I look at my 1997 list in 2022 and both despair and laugh at what passed for a production deployment back then. For a modestly critical system for what is basically a ~50,000 person company. No-code trades short-term easier for medium- and long-term harder.
I can't even imagine what legacy no-code will look like and what a nightmare it will be. Without sarcasm, I'm sure it will make the 20-year-old, umpty thousand line Perl code base that I was also in last week look like paradise.
No-code is great for exploration of problems, and for all I may seem to be slagging on it here, I believe it has a place and it is worth exploring. But it is sheer foolishness to think it can "solve overworked IT department"'s problems. A no-code solution would ...
/me standing up from seat and clapping loudly
Could you please share a few examples of best practices not followed?
Power Apps: A raw app is easy to get running but a nice app that does what I want is hacky.
Pentaho Data Integration: Super easy to use and maintain.
MS Access: Fast development and you can do actual programming if need be.
Among these tools, I just don't see a need for power apps and desktop apps written in MS Access are not something people are looking for any more. PDI on the other hand makes it easy to ETL data and has saved me countless hours over the years.
Or they are workflow tools, sold with simple graphical demos of easy state machines / START -> box -> box -> box -> DONE flows, but when the rubber hits the road you encounter branching, loops, retries, subroutines, error codes, suspended/paused flows, state management, and full on turing machine processing.
Or they are AI tools, and you are relying on statistical probabilities that the code does what you want to, and statistical probabilities that the AI isn't producing the answer that looks right and the one you want versus the actual answer?
Or you are writing so much testing/quality control /verification that you might as well have coded in the first place?
Finally, you are invariably dealing with a vendor, and massive massive massive vendor lockin. Have fun when Oracle acquires them, triples the price, and audits you every other year.
I do feel like there is a solution here. On the dev side, what should be simple business apps written in code are too complex, and have too much cruft. Upgrading frameworks is a hassle. It should be easier.
I feel like a popular really well done open source AI code generation tool could solve this and is waiting to be written.
This is one of the biggest challenges I see people struggling with as they learn programming: Cutting out the implicit assumptions that humans make every time they communicate with each other, and interactively working to understand *exactly* what needs to happen and why.
Interactive AIs (e.g., Copilot, ChatGPT), in principle, could address the specification problem. Unfortunately, in their current state, they have no concept of what they don't know or understand. Gaps in the specification are filled in with assumptions, and one of the main criticisms of these tools at the moment is that they have no way to reason about how appropriate these assumptions are. It seems likely that we'll eventually reach a point where simple AIs can replace devs for the relatively simple tasks that low/no-code solutions target. However, for this to happen, (i) the AI would need the ability to reason about uncertainty/incompleteness in the prompt it's given, and (ii) the AI would need to be able to interactively work with the user to refine the specification.
For me it sounds like another Web3AIBlockchainVRMeta fad, like those trends in history: romanticism, baroque, enlightenment, etc.
That said, as development tool chains grow in options and complexity , I do see these things as being a bridge for some people to get their feet wet. Self taught devs can start here and then code later when needed. But that’s just a theoretical use case/market void that may not really exist.
Anything more complicated - you are looking at mountain of glue scripting to stich together different parts and maintaining that frankenstein of code
The one area I find a bit concerning is governance/management around the data and permissions low-code apps ask. In a powerapps context for example, the app might ask permissions to read all your onedrive, sharepoint or email and it may even have a good reason to do so but now that means if the regular user who composed it gets compromised, threat actors get all that data from the user's of the powerapp.
I am guessing other low code frameworks also work with some business or user data. Low code means easy to compose and less low level coding error related vulns but you can still have a vulnerable low code app.