> No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.
I don't want to dismiss this point, because it's real. But there is an alternative.
I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt.
If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it.
We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time.
So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.
I work for a low code vendor, and use that ikea example quite a lot. Fact is, most people can’t or won’t afford a carpenter but would rather save time and money by using ikea furniture. I believe there’s a market for ikea software and I believe that there are many organizations that would rather spend money on ikea software than on expensive, slow and scarce software carpenters. And we’re software engineers building the low code platform, so we understand the value of version control, testing, automated deployments and apis…
I don't want to dismiss this point, because it's real. But there is an alternative.
I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt.
If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it.
We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time.
So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.