Low-code is not a cure for overworked IT departments(zdnet.com)
zdnet.com
Low-code is not a cure for overworked IT departments
https://www.zdnet.com/article/low-code-is-not-a-cure-for-overworked-it-departments-just-yet/
211 comments
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.
"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.
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.
Software is a team sport.
[1] https://en.wikipedia.org/wiki/Shaolin_Soccer
Software is a team sport.
[1] https://en.wikipedia.org/wiki/Shaolin_Soccer
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.
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.
> "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.)
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.)
> The tech department has better working conditions that most other departments.
How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?
How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?
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.
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).
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.
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.
> frankly totally unqualified people seeking SWE positions
PLEASE explain to me what value leetcode-type questions provide over what good of a software engineer someone is!
PLEASE explain to me what value leetcode-type questions provide over what good of a software engineer someone is!
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.)
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.)
> Imagine you had an automated oracle
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.
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.
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.
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.
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.
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.
[deleted]
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.
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.
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.
> Is being on call really a sign of low status?
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.
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.
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.
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.
[deleted]
Being cushy isn’t high status.
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.
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.
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.
Please get some perspective not everyone is in your situation.
[deleted]
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 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.
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".
Your lucky if they had a two-day course on "agile". And Doctors have rounds where they talk about what the status update of their patients.
Well, patients are important. Reinventing the wheel because your company suffers from NIH syndrome is not.
Software engineers already automated that. We know if the server is down.
Do you happen to know what kind of BS doctors have to put up every day?
Care to outline it for me?
Care to outline it for me?
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.
> private capital sucks the juice out of everyone unlese we fight back.
They're even busier in public hosptials btw
They're even busier in public hosptials btw
Sure, show me the two-day course I can take that enables me to work in a hospital micro-managing the doctors.
Sales and Marketing both deal with this and have for much longer than software developers.
Having worked sales. You got asked what you've done today multiple times during the day.
Yeah, same. Once per day would be a dream.
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.
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.
Kids in US public schools stop getting micromanaged like this around first grade. Tech workers are treated like toddlers.
What will happen if you will tell your manager that you will not visit those standups anymore? Will you be fired?
>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]
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]
>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.
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.
[deleted]
> you're possibly dependent on a third party to fix the bug.
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.
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.
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.
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.
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.
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.
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.
"No such thing as unskilled labor" really not something they can handle huh?
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.
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.
You're just being pedantic that's exactly what skilled vs unskilled labor means.
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).
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.
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.
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.
I'm curious exactly what that toxic and pissy behavior looks like, and how it's motivated. Is it just because he's making them look bad?
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.
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.
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.
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.
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.
It’s not that simple though, is it.
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.
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.
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.
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.
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.
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
> 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...)
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...)
Could replace S3 with a self hosted Minio instance?
You can, but S3 has a special place in my heart as I worked there. I know a lot of the deep details.
I wish it was cheaper, but I can leverage it well.
I wish it was cheaper, but I can leverage it well.
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
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/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.
> There is one thing that works in tech, and boss man doesn't want to hear it: pay a small team of good developers a good wage and treat them well.
And have a compelling product ...
And have a compelling product ...
No, no. Go right ahead and sink time and money into this sort of crap. Just like every attempt before, it'll generate a pile of garbage that's unmaintainable yet will still manage to poop out ONE single nugget of value: determining what needs to be built after the idiot suits thrashed all around with the 'wonder toy' system. Then, we experienced developers can have a walk in the park while cashing out on contracting rates. Fat stacks of cash simply for replacing exact like-for-like functionality with REAL software and then bring in the extensions the vendor toy systems couldn't. I could do with a nice, easy, early retirement path to pop up in 7 years. Bring it on ;)
I'm frequently on that receiving end of low-code implementations that have failed, and I'm not quite as fond of it as you. ;^)
The problem is reasoning. Often the low code limitations funnels the implementation into a contorted state, so by the time they've decide to give up what I get is frequently exceptionally difficult to comprehend. Usually I peek at it, try to get an idea, and then do what I would have done if assigned to task from the get-go - read (or make) a spec, and go from there. I'm doing some quick napkin calculations from the time tracking system, and the ratio is approximately 13/2 on the last 7 of these no-code to code tasks. What they attempt in no-code in 13 hours and fail I finish in, yes, 2. Given, these are not developers, and sometimes these actually come from the CEO (who does not track their time so they're not in that ratio), but mostly they're just managers and remote hires. And I've been developing software for 28 years now, so I have some capability. Also, these are mainly data related projects, so maybe other types of work would have more success.
No code will get better, I'm sure, but the problems we're solving actually are getting harder (it seems to me) and reasoning about them is the difficult part. I'm not sure how to no-code that.
The problem is reasoning. Often the low code limitations funnels the implementation into a contorted state, so by the time they've decide to give up what I get is frequently exceptionally difficult to comprehend. Usually I peek at it, try to get an idea, and then do what I would have done if assigned to task from the get-go - read (or make) a spec, and go from there. I'm doing some quick napkin calculations from the time tracking system, and the ratio is approximately 13/2 on the last 7 of these no-code to code tasks. What they attempt in no-code in 13 hours and fail I finish in, yes, 2. Given, these are not developers, and sometimes these actually come from the CEO (who does not track their time so they're not in that ratio), but mostly they're just managers and remote hires. And I've been developing software for 28 years now, so I have some capability. Also, these are mainly data related projects, so maybe other types of work would have more success.
No code will get better, I'm sure, but the problems we're solving actually are getting harder (it seems to me) and reasoning about them is the difficult part. I'm not sure how to no-code that.
"Those who don't know history are doomed to repeat it." I haven't seen any "low-code" tool with technology and ideas noticeably beyond what such tools tried in the 90's. If there were some kind of breakthrough that gave such tools something earlier tries didn't have, then maybe it would be time to take a new look. But until then, I'll remain skeptical. Remember Steve Balmer's smarter brother: "Maintenance, maintenance, maintenance!" (hypothetical brother)
It's interesting how we have decades of knowledge and experience that sales people typically blow smoke up the execs you-know-what and fail to deliver to various degrees yet those execs are still gung-ho on implementing expensive 'solutions'. I've seen it where the people below them that have to do the day-to-day work on it have other ideas but are then forced to use these platforms and explain it to those execs, and why they may not be working.
I wonder if it's because some of those at the mid-to-level making these decisions are under the same market pressures as the rest of us to show they've actually 'done sometime' - so they can slap this on a resume and prepare it for an interview when they roll out of the org in a year or two after implementation. This seemed to be the history in the IT department at the hospital I worked out where they had a decade of zombie projects that sorta worked because they were implemented, barely supported, and the persons that made the decision had bounced to something else, leaving IT holding the bag.
I wonder if it's because some of those at the mid-to-level making these decisions are under the same market pressures as the rest of us to show they've actually 'done sometime' - so they can slap this on a resume and prepare it for an interview when they roll out of the org in a year or two after implementation. This seemed to be the history in the IT department at the hospital I worked out where they had a decade of zombie projects that sorta worked because they were implemented, barely supported, and the persons that made the decision had bounced to something else, leaving IT holding the bag.
"I wonder if it's because some of those at the mid-to-level making these decisions are under the same market pressures as the rest of us to show they've actually 'done sometime'"
Definitely true. Also don't discount the influence of good old fashioned corruption - cash kickbacks, job promises, gifts, etc., I've seen IT contracting decisions so dumb that graft is far and away the most logical explanation.
Definitely true. Also don't discount the influence of good old fashioned corruption - cash kickbacks, job promises, gifts, etc., I've seen IT contracting decisions so dumb that graft is far and away the most logical explanation.
This is exactly what the "booming" HRTech sector is doing right now, crazy stuff going on
Yes please. Do the same with ai generated code.
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".
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.
Exactly. A configuration change is the same as a code change: it should be tested and reviewed before it goes live
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.
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.
You don't pay a great team of engineers for a solution today. You pay them for the agility it gives you tomorrow.
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.
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.
That's true, but if you don't pay in advance for well-written software, you are not going to get it later.
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.
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.
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.
Well said!
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.
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.
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:
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 be lucky to make it easier in the short term, but even if it manages that, the medium and long term graphs of difficulty are a nightmare. As a professional programmer, I'd LOVE to just be able to bash on code and not worry about backups and staging and rollbacks and QA and source control and all this other stuff. I'm not doing these things to gatekeep, I'm doing it because I need to!
To put it in physical terms, sometimes I think no-code is like someone passing highway construction and asking "What's with all these people? What's with all these machines? What's so hard about highway construction, it's just concrete on the ground, right? We don't need centralized planning and all this money! Let's just give shovels out to everybody and some cement mixers and turn them loose!" Well, you know, arming people with shovels and cement mixers can be very empowering in certain circumstances. But try to build a local city network that way and you're just going to reinvent everything you threw away, because it turns out trying to drive thousands of semi trucks a day at 70mph down a path some guys shoveled out and poured a bit of concrete over doesn't work.
* 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
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 be lucky to make it easier in the short term, but even if it manages that, the medium and long term graphs of difficulty are a nightmare. As a professional programmer, I'd LOVE to just be able to bash on code and not worry about backups and staging and rollbacks and QA and source control and all this other stuff. I'm not doing these things to gatekeep, I'm doing it because I need to!
To put it in physical terms, sometimes I think no-code is like someone passing highway construction and asking "What's with all these people? What's with all these machines? What's so hard about highway construction, it's just concrete on the ground, right? We don't need centralized planning and all this money! Let's just give shovels out to everybody and some cement mixers and turn them loose!" Well, you know, arming people with shovels and cement mixers can be very empowering in certain circumstances. But try to build a local city network that way and you're just going to reinvent everything you threw away, because it turns out trying to drive thousands of semi trucks a day at 70mph down a path some guys shoveled out and poured a bit of concrete over doesn't work.
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 :-)
/me standing up from seat and clapping loudly
/me standing up from seat and clapping loudly
> certainly wasn't following 2022 best practices by any means
Could you please share a few examples of best practices not followed?
Could you please share a few examples of best practices not followed?
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.
[deleted]
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.”
Nope, project was already rolling full steam ahead before I joined.
I was once a part of a team who's job it was to create a low/no code solution for our product.
The issue we hit square in the face is that while it was easy for our C level person to say "Yeah, this is simple, let's just make a low code solution!" when rubber hit the road and we started asking "but, what should this DO. What sort of solution do you want?" we got nothing but "We want it to do everything, but we also want that in the next 3 months".
In other words, they wanted a full blown programming language and integration with our legacy system (with literally 1000s of datapoints) all done with like 5 devs and no requirements other than "everything" and a PM that couldn't give us a "we are successful if we can do x" sort of usecase.
Needless to say, it was a giant CF and failure.
On the flip side, the low/no code solution that I've seen work unreasonably well was doing a custom groovy dsl hooked into the necessary bits doing data transforms. It worked great for us in dev because we simply wired in an existing language and it worked great for the product because the people writing the groovy scripts were easier to hire (and often got moved over to dev if they were good enough!).
The issue we hit square in the face is that while it was easy for our C level person to say "Yeah, this is simple, let's just make a low code solution!" when rubber hit the road and we started asking "but, what should this DO. What sort of solution do you want?" we got nothing but "We want it to do everything, but we also want that in the next 3 months".
In other words, they wanted a full blown programming language and integration with our legacy system (with literally 1000s of datapoints) all done with like 5 devs and no requirements other than "everything" and a PM that couldn't give us a "we are successful if we can do x" sort of usecase.
Needless to say, it was a giant CF and failure.
On the flip side, the low/no code solution that I've seen work unreasonably well was doing a custom groovy dsl hooked into the necessary bits doing data transforms. It worked great for us in dev because we simply wired in an existing language and it worked great for the product because the people writing the groovy scripts were easier to hire (and often got moved over to dev if they were good enough!).
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.
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.
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.
Spot on. I tell people all the time my job is to translate from English into Nerd.
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.
Low-code/no-code is a mirage in the desert. The illusion is that complexity, cost, and difficulty are the result of "code". Code is actually extraordinarily simple. The simplicity makes it almost infinitely flexible, and because it's so flexible, it's often used to solve very difficult problems.
This leads business executives to think that it's the "code" that is difficult.
This leads business executives to think that it's the "code" that is difficult.
Bingo! Syntax is almost never _the_ problem.
For me, the main issues of low-code/no-code tools are:
1. Leaky abstractions. Our industry has been developing software for decades, and we almost generally agree that MVC-like architectures offer the best ratio of flexibility-to-productivity. How am I supposed to trust that an abstraction made by the low-code/no-code tool will allow me to implement even a slightly less-common use-case? When I use these tools, I'm constantly 1 use-case away from having to throw everything away and start from scratch using something else.
2. It doesn't solve the most prominent problem - designing the system. Implementing the software is in fact very straightforward and isn't that time consuming. On the other hand, having to think of all the use-cases that your application needs to support, thinking of all the edge-cases and less-obvious quirks is 2 orders of magnitude harded.
3. The highest degree of vendor-lock.
4. Not clearly stating what their limitations are.
I'm not entirely dismissing the idea, and I believe these tools can be helpful in some cases. But I believe that more often than not, people don't get the promised outcome, or even if they do, it doesn't come without significant tradeoffs.
In my oppinion, the better approach to save the time of your development team is to just give them better tools. Tools, that don't require them to completely dismiss the workflows and architectures they are used to. But rather tools, that just improve and simplify what they are already doing.
This was also my main goal when designing https://stacktape.com
I wanted to create a tool, that provides the highest possible level of simplification of DevOps, while at the same time being flexible to cover any-use case. I also very clearly state our limitations - it's only for AWS. If that's a dealbreaker, you won't need to spend 2 weeks to figure that out.
1. Leaky abstractions. Our industry has been developing software for decades, and we almost generally agree that MVC-like architectures offer the best ratio of flexibility-to-productivity. How am I supposed to trust that an abstraction made by the low-code/no-code tool will allow me to implement even a slightly less-common use-case? When I use these tools, I'm constantly 1 use-case away from having to throw everything away and start from scratch using something else.
2. It doesn't solve the most prominent problem - designing the system. Implementing the software is in fact very straightforward and isn't that time consuming. On the other hand, having to think of all the use-cases that your application needs to support, thinking of all the edge-cases and less-obvious quirks is 2 orders of magnitude harded.
3. The highest degree of vendor-lock.
4. Not clearly stating what their limitations are.
I'm not entirely dismissing the idea, and I believe these tools can be helpful in some cases. But I believe that more often than not, people don't get the promised outcome, or even if they do, it doesn't come without significant tradeoffs.
In my oppinion, the better approach to save the time of your development team is to just give them better tools. Tools, that don't require them to completely dismiss the workflows and architectures they are used to. But rather tools, that just improve and simplify what they are already doing.
This was also my main goal when designing https://stacktape.com
I wanted to create a tool, that provides the highest possible level of simplification of DevOps, while at the same time being flexible to cover any-use case. I also very clearly state our limitations - it's only for AWS. If that's a dealbreaker, you won't need to spend 2 weeks to figure that out.
I think the end goal of most low-code/no-code tools to be something where you can get an 80% solution without hiring a real engineer. The second part of that sentence is really important.
Should large businesses going to build their most critical functions into a low-code solution? No, not at all. But one slightly technical person in e.g. the marketing department can unlock a lot of business value but automating a few workflows.
Should large businesses going to build their most critical functions into a low-code solution? No, not at all. But one slightly technical person in e.g. the marketing department can unlock a lot of business value but automating a few workflows.
Salesforce does this pretty well. Allowing users to put something together to automate a business process quickly.
Their concept of custom tabs, custom objects, fields, page layouts and the way different layouts are assigned to groups of users by profile make it easy to stand up a lot of record keeping and management that's needed in a lot of plain boring business.
Granted, Salesforce is so immensely wide and deep that many of those advantages get lost in the complexity of the platform itself.
Their concept of custom tabs, custom objects, fields, page layouts and the way different layouts are assigned to groups of users by profile make it easy to stand up a lot of record keeping and management that's needed in a lot of plain boring business.
Granted, Salesforce is so immensely wide and deep that many of those advantages get lost in the complexity of the platform itself.
This is exactly something I don't necessarily agree with.
I think that this "slightly technical person" won't be able to create that application/workflow with a sufficiently high-enough quality.
Is he going to think about all of the edge-cases? Does he know how to properly validate user inputs?
Also, quoting from the article: "Interestingly, while low-code/no-code are seen as the tool of citizen developers, its primary users are IT professionals, the Capterra survey also shows."
I think that this "slightly technical person" won't be able to create that application/workflow with a sufficiently high-enough quality.
Is he going to think about all of the edge-cases? Does he know how to properly validate user inputs?
Also, quoting from the article: "Interestingly, while low-code/no-code are seen as the tool of citizen developers, its primary users are IT professionals, the Capterra survey also shows."
I see the arrogance of devs here who think scalability and performance are the core metrics. They are not. Outside of security, its the customer requirement that takes priority. We can point to a mountain of well written software that the customers wont touch with a ten feet pole.
The trouble is treating No-code as the final product. Its the MVP that can be rapidly iterated which the end customers can play around to visualize and make sense of the product. This helps to understand what the customer wants and if it makes significant improvement to their workflow and creates value. It helps to streamline requirements and get you as close to final design as possible. Any executive worth their value should not be paying smart engineers to build a product that noone is going to use.
The trouble is treating No-code as the final product. Its the MVP that can be rapidly iterated which the end customers can play around to visualize and make sense of the product. This helps to understand what the customer wants and if it makes significant improvement to their workflow and creates value. It helps to streamline requirements and get you as close to final design as possible. Any executive worth their value should not be paying smart engineers to build a product that noone is going to use.
That's the right approach to higher-level tools such as no/low-code! Trying to model your problem using a pre-built software gives you constraints to think about, provides you with an alternative data model from the one in your mind / paper, and can obviously validate an idea with a few days instead of weeks/months!
But besides this point, when the problem is now well understood, no/low-code is just like walking with rocks in the shoes: you think it will go away by itself and you end-up with bleeding toes in the evening!
But besides this point, when the problem is now well understood, no/low-code is just like walking with rocks in the shoes: you think it will go away by itself and you end-up with bleeding toes in the evening!
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.
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.
> 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.
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.
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.
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.
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. ;)
[0] https://alan-platform.com/
[1] https://structr.com/
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/
I wonder if it would be possible to have a no-code tool that
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
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
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.
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.
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.
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.
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.
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...
I’ve seen things, too...
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...
The sooner the better. Would you prefer stage one cancer or stage four cancer?
> The problem with these generative systems is that they're synthesizing existing code and their output isnt therefore always valid
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.
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.
>> You simply channel inputs to the LLM, collect API calls from the LLM, and execute the API calls it makes.
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.
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.
And we will be able to blame production melting down on "AI" misinterpreting what someone said.
"I told it to delete users from my contact list, not just delete them from system!"
"I told it to delete users from my contact list, not just delete them from system!"
100% someone would say 'delete the users from my contact list in the system'
Fortunately, the business user to analyst to dev game of telephone with people never results in misinterpretations that survive to production.
Instead of low-code solutions, we need to better empower data analysts and data engineers to solve problems for BUs. DSLs, API access, config files, templates, etc.
Devs own the infrastructure. BUs own the business logic. Data analysts and data engineers are embedded in BUs, and they're the primary people involved in getting the platforms devs own to service business needs. Instead of giving them low-code garbage, give them an API to call, SQL access, and the ability to build, run, and distribute python applications.
Data analysts are the layer between devs and operations that can solve the problems and ease the natural tensions that arise between devs and ops. Support the data analysts and data engineers.
Don't buy into low-code sales pitches.
Devs own the infrastructure. BUs own the business logic. Data analysts and data engineers are embedded in BUs, and they're the primary people involved in getting the platforms devs own to service business needs. Instead of giving them low-code garbage, give them an API to call, SQL access, and the ability to build, run, and distribute python applications.
Data analysts are the layer between devs and operations that can solve the problems and ease the natural tensions that arise between devs and ops. Support the data analysts and data engineers.
Don't buy into low-code sales pitches.
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.
The quality of IT reporting continues to disappoint.
The idea of no-code/low-code is to lower barriers to entry. This is a process that started with the invention of C, continued with the much-despised COBOL, and had perhaps its greatest success with Microsoft Visual Basic macros. Yes, professional developers complained about the quality of that code, but it was a boon for many offices and was wildly popular. The idea is to make programming available to more and more people, so that with macros even secretaries could automate some Windows office tasks without needing to learn C++.
This is just a continuation of that process of trying to lower the entry bar for deploying automation. You are not going to write an auto-safety feature or build a load balancer using these technologies, but you are going to allow someone on the margins to automate a data entry process or put together a simple series of webviews.
However if you provide someone with a new tool to take on a new role, that isn't going to solve the problem of the person being too busy with all their existing roles. That's a completely different problem. Of course low-code isn't a cure for someone being overworked. It's meant to help someone with a lower skill level take on new work.
The idea of no-code/low-code is to lower barriers to entry. This is a process that started with the invention of C, continued with the much-despised COBOL, and had perhaps its greatest success with Microsoft Visual Basic macros. Yes, professional developers complained about the quality of that code, but it was a boon for many offices and was wildly popular. The idea is to make programming available to more and more people, so that with macros even secretaries could automate some Windows office tasks without needing to learn C++.
This is just a continuation of that process of trying to lower the entry bar for deploying automation. You are not going to write an auto-safety feature or build a load balancer using these technologies, but you are going to allow someone on the margins to automate a data entry process or put together a simple series of webviews.
However if you provide someone with a new tool to take on a new role, that isn't going to solve the problem of the person being too busy with all their existing roles. That's a completely different problem. Of course low-code isn't a cure for someone being overworked. It's meant to help someone with a lower skill level take on new work.
Not sure if serious... COBOL was one of the earliest 3rd gen programming languages. Back then no one had a clue what high-level programming would ultimately look like, so "make it read kinda like English" was a nice first try at the problem.
(There were also highly pragmatic reasons behind that, such as the paucity of common symbols in the non-standard character sets that were used back then. This shows up in other early languages, but nowhere so clearly as in COBOL.)
Nowadays we know that the "low code" paradigm does not help beyond absolutely trivial examples. In particular it does not make the resulting artifacts easier to audit or survey, rather the opposite.
(There were also highly pragmatic reasons behind that, such as the paucity of common symbols in the non-standard character sets that were used back then. This shows up in other early languages, but nowhere so clearly as in COBOL.)
Nowadays we know that the "low code" paradigm does not help beyond absolutely trivial examples. In particular it does not make the resulting artifacts easier to audit or survey, rather the opposite.
Not sure if you read my post, but yes I used COBOL as an example of a high level language because it was one of the first attempts. That is what the phrase "long line" refers to. A historical look back at the earliest attempts to do this.
Also, the idea of lowering the bar does not mean you spend 50 years on doing the same thing over and over again. This is also the point I made. First, they dropped the requirement to program in Assembly and created higher level languages such as C or COBOL. Then they dropped the requirement of having a separate toolchain/build infrastructure and created VisualBasic. It is quite foolish to think that VisualBasic was popular because of its syntax. VisualBasic was popular because the developer environment/runtime were bundled into the office suite. Programs were extremely portable and the runtime was everywhere. It is the same reason that javascript became popular. That got rid of a lot of infrastructure and lowered the entry bar. It was the macro feature that made it a success, not the syntax. Then comes the no-code toolkits which have drag and drop and other features which you can get really distracted by, but they really work on the basis of a fixed set of libraries and a fixed set of calling conventions that is intended to simplify the chores of library selection and invocation. Again, the point is to remove or simplify something by automatically providing it.
How much of a success it is will depend on how good it is at removing complexity for the set of tasks it is designed to tackle, which will ultimately be decided by market adoption. But one thing these tools cannot do, is free up people who are already busy. What they can do is lower the entry bar so people who wouldn't be productive because the barriers to entry are too high can be productive at rolling out simple automation tasks. The Marketing exec rolling out some clumsy dashboard reporting tool via a no-code process is the natural evolution of the secretary creating a form with visualbasic, which is itself the natural evolution of an accountant writing a script that calculates a depreciation schedule with COBOL.
Also, the idea of lowering the bar does not mean you spend 50 years on doing the same thing over and over again. This is also the point I made. First, they dropped the requirement to program in Assembly and created higher level languages such as C or COBOL. Then they dropped the requirement of having a separate toolchain/build infrastructure and created VisualBasic. It is quite foolish to think that VisualBasic was popular because of its syntax. VisualBasic was popular because the developer environment/runtime were bundled into the office suite. Programs were extremely portable and the runtime was everywhere. It is the same reason that javascript became popular. That got rid of a lot of infrastructure and lowered the entry bar. It was the macro feature that made it a success, not the syntax. Then comes the no-code toolkits which have drag and drop and other features which you can get really distracted by, but they really work on the basis of a fixed set of libraries and a fixed set of calling conventions that is intended to simplify the chores of library selection and invocation. Again, the point is to remove or simplify something by automatically providing it.
How much of a success it is will depend on how good it is at removing complexity for the set of tasks it is designed to tackle, which will ultimately be decided by market adoption. But one thing these tools cannot do, is free up people who are already busy. What they can do is lower the entry bar so people who wouldn't be productive because the barriers to entry are too high can be productive at rolling out simple automation tasks. The Marketing exec rolling out some clumsy dashboard reporting tool via a no-code process is the natural evolution of the secretary creating a form with visualbasic, which is itself the natural evolution of an accountant writing a script that calculates a depreciation schedule with COBOL.
My own experience with a few low/no code tools:
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.
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.
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.
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 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.
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.
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.
Yep you nailed it.
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.
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.
> 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.
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.
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.
[deleted]
I think a lot of times the problem that people want low code to solve isn't IT being overworked but IT being out of their control.
To put it another way, I think the demand for it is often just another manifestation of Conway's Law.
To put it another way, I think the demand for it is often just another manifestation of Conway's Law.
Exactly, there's a huge appetite for products that allow Marketing, for example, to get things done without IT involvement; I'm not sure why people are surprised that other departments want to do the same.
I think that low-code platforms can fill a need where they can help a team iterate on a solution without IT and get to a 80% solution that solves real problems, then bring in IT to help productize it rather than trying to start from scratch.
I think that low-code platforms can fill a need where they can help a team iterate on a solution without IT and get to a 80% solution that solves real problems, then bring in IT to help productize it rather than trying to start from scratch.
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?
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?
wordpress has modeled this for ahhh almost 2 decades? infer what you will from that analogy ;)
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.
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'm having an ok career in this space contorting Excel, Access, SQL, VBA and Powershell. It's going ok, but I do have to point out one thing that this hype cycle is missing. You are explicitly developing software by people who have never taken data structures, or algorithms or software design. The people developing these tools do not understand what a dictionary is and why you would use it, do not understand when and why you would use memory as opposed to disk, and routinely do things like triply nested loops rather than something sane. And that's before we consider that the tools themselves are nerfed and do not allow you to do things beyond their limits, usually something involving database size.
So, yeah, this is going to be a mess. Fight it, fight it hard and this is just another attempt by the MBA class to devalue skilled labor. Call it like it is, and if they built it and owned it, they can maintain it.
So, yeah, this is going to be a mess. Fight it, fight it hard and this is just another attempt by the MBA class to devalue skilled labor. Call it like it is, and if they built it and owned it, they can maintain it.
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
Anything more complicated - you are looking at mountain of glue scripting to stich together different parts and maintaining that frankenstein of code
I think that low code has some promising application areas, just not building operational systems;
1. As a requirements gathering (business prototype?) tool (the outcome is a spec used to develop the real system).
2. As a 'leverage' tool to magnify experienced coders time.
3. As a 'partial' core in an operational system written by coders (the business engine), but that's just rules based and has been around for ages.
Drag and dropping boxes with arrows for a fully operational system? yeah haven't we already being trying this for decades, quite unsuccessfully? I'm more intrigued by the idea of using AI to generate acceptable boilerplate crap (eg CRUD crap) and still think very high level languages has potential (small, focused DSL).
A lot of frustrated, abused coders here in the threads, I feel it to.
Drag and dropping boxes with arrows for a fully operational system? yeah haven't we already being trying this for decades, quite unsuccessfully? I'm more intrigued by the idea of using AI to generate acceptable boilerplate crap (eg CRUD crap) and still think very high level languages has potential (small, focused DSL).
A lot of frustrated, abused coders here in the threads, I feel it to.
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.
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.
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.
Isn't it even worse than "get all of the data"? Don't you also gain the ability to impersonate anyone who clicks through to the app?
Delegatedimpersonation is possible in an AAD context so technially they can request that but I'm not sure the lowcode UI would let them.
Yeah the only low code I respect is excel.
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 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.
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.
I've been programming all my life, it's great to have the power to do almost anything logical with a computer. But even just CRUD can be a complicated hassle.
Most APIs have idiosyncrasies that you don't learn from the docs. With Zapier for example I can wire A to B without having to setup a project, repo, dependencies, look at docs, error handling, I don't know 100 other things? That's awesome.
Would I build, like, Honeywell's procurement system with a tool like that? No way.
Most APIs have idiosyncrasies that you don't learn from the docs. With Zapier for example I can wire A to B without having to setup a project, repo, dependencies, look at docs, error handling, I don't know 100 other things? That's awesome.
Would I build, like, Honeywell's procurement system with a tool like that? No way.
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
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
In a lot of areas the cure is just hiring the right amount of people instead of trying to milk every last drop of work out of the existing workforce.
Parcel delivery sucks because the routes the normal delivery person has to drive are so on edge that even the slightest anomaly will produce delays. I'd happily pay a euro more for shipping that does not suck and the employees would happily work in such an environment. Still it does not happen, because somehow somewhere someone decided this was the way it should be.
Same for IT. Want things not to suck? Just hire the right amount of people, pay them the right amount of salary (to get the right amount of expertise) and you are good to go. Don't want to spent that money? Then you are paying every day for the money you saved there.
Parcel delivery sucks because the routes the normal delivery person has to drive are so on edge that even the slightest anomaly will produce delays. I'd happily pay a euro more for shipping that does not suck and the employees would happily work in such an environment. Still it does not happen, because somehow somewhere someone decided this was the way it should be.
Same for IT. Want things not to suck? Just hire the right amount of people, pay them the right amount of salary (to get the right amount of expertise) and you are good to go. Don't want to spent that money? Then you are paying every day for the money you saved there.
What are examples of 'low-code'/'no-code' approaches/products used by PMs?
Perhaps Mendix, Bubble, AppSheet, and QuickBase fit the bill.
While everybody is arguing about how useful low-code/nocode is to IT departments, the people that actually need to get stuff done are just writing it themselves in Excel. It may not be the best software engineering, but it gets stuff done with a minimum of fuss.
IT departments are not overworked.
They are burned out. Not overworked.
Burn out is malfunction of the meaning.
Somehow non-technical people managed to remove the meaning for the technical people. Is anybody surprised?
Fix is simple. Remove management insert leadership. Simple, not easy.
They are burned out. Not overworked.
Burn out is malfunction of the meaning.
Somehow non-technical people managed to remove the meaning for the technical people. Is anybody surprised?
Fix is simple. Remove management insert leadership. Simple, not easy.
We had a bout of a naive executive who wanted to "replace programmers" with such "instant" tools (MS-Power-stuff, cough cough). His team was frustrated that IT was skeptical. I had to write up a 4 page description of why we should tread slowly. Fortunately staff turnover not related to IT ended the nightmare.
I used a motel vs. house analogy. But you had to assume it's not easy to move out of a motel for the analogy work. I'm still looking for a better analogy from the everyday world; some variation of a stitch-in-time-saves-nine.
I used a motel vs. house analogy. But you had to assume it's not easy to move out of a motel for the analogy work. I'm still looking for a better analogy from the everyday world; some variation of a stitch-in-time-saves-nine.
>Using low-code and no-code platforms is supposed to provide relief to overworked development shops, right?
No, you got it wrong, zdnet. No-code is for people who don't do software development. It's for finance analysts, marketing managers, and similar non-technical professions.
Also, no-code isn't something new. Non-technical people have been using a no-code tool for decades. It's called Excel. Now they just have more options.
No, you got it wrong, zdnet. No-code is for people who don't do software development. It's for finance analysts, marketing managers, and similar non-technical professions.
Also, no-code isn't something new. Non-technical people have been using a no-code tool for decades. It's called Excel. Now they just have more options.
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.
IKEA’s knowledge graph and why it has three layers: https://news.ycombinator.com/item?id=32749633
IKEA’s knowledge graph and why it has three layers: https://news.ycombinator.com/item?id=32749633
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.
Low code makes more work because now product people can create very intricate demos, and expect us to turn them into features.
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.
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.
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.
It seems it comes back every year or two, coincidentally on market downturns.
The Capterra post that zdnet refers to: https://www.capterra.com/resources/how-pms-can-use-low-code-...
It's worth noting that these low-code solutions indirectly drive usage of the SaaS products that Capterra lists and analyzes.
low-code is a good way of preventing all the controls that development tools normally provide. Had to deal with these headaches when a team insisted on using Apache NIFI. You get merge problems, you can't examine changes on their own, you get one environment to test things (i.e. production) and if it breaks rolling back is extremely non-trivial.
All that work that could be done automatically by tools now has to be done by people showing restraint and following process. And these are the people who want a low-code solution so understand the problems far less.
It's a nightmare. Going to be good money to come in and clean it up later though.
All that work that could be done automatically by tools now has to be done by people showing restraint and following process. And these are the people who want a low-code solution so understand the problems far less.
It's a nightmare. Going to be good money to come in and clean it up later though.
There's definitely no reason to be skeptical of the self-reported results from managers that have an obvious conflict of interest when it comes to reporting whether the low code tools they advocated for were a good idea
In the meantime, most personnel in IT department do not have time for newer apps to be integrated as they are still battling against the organization of Active Directory made 20 years ago... (only half joking unfortunately)
[deleted]
Low code solutions are great for what they call "Shadow IT".
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
shh, don't tell them the secret of job security. low code platforms have no version control system like git. it's perfect way to create silos of knowledge
Low code was more time consuming than just writing ETLs
<searches TFA for the word "lollipop">
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.
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.
So spot on! +100 this!
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.
> 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.
[1] https://towardsdatascience.com/i-used-chatgpt-to-create-an-e...
[1] https://towardsdatascience.com/i-used-chatgpt-to-create-an-e...
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.
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.
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 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 think this is exactly where the value is - I commented similar on this thread (didn't see you comment..)
[deleted]
since when has writing the code been the hard part/blocker for this stuff lol
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).
sounds like optimism we saw with self driving cars
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.
No code won't fill all needs but they have a place in business.
Are you a programmer? Or are you basing this off the results that programmers have been getting out of the tool?
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.
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.
I don't see the benefit of creating code with ChatGPT. I can already get code for next to nothing by outsourcing.
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).
The second a difficult bug arises in your low-code (or, now, GPT-generated) solution, good luck.