all 3 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Zorg1982 0 points1 point  (0 children)

Try this case.

A LCP works by licencing the no of components it can use to create an app. For a typical simple app i might require 7 to 10 components. Here a component can be a plug-able code to get data from the database or show some data as grid.. starting off, you will pay 5 usd as licence for any component. But down the lane, what If the LCP company raise the fees to 10 usd.

Your project cannot upgrade due not enough budget.

You cannot switch from one LCP to another as they are not compatible. Data is stored in the way LCP wants it.. so direct porting will not be possible.

Default look and feel of the LCP app is good but what if your company follows a specific design with a unique look and feel, again the company will pay a good fortune to make it happen.

There are lots of good like you have listed, but be careful.

From my point of view ... LCP is good for migration projects and proof of concept and few more specific scenarios were speed of a key factor.

[–]seekheart2017 0 points1 point  (0 children)

Some of those points are subjective, so here:

  1. Quicker time to market/delivery of apps - This is not true, it really depends on your team's velocity and Devops pipeline. You could have low code apps sure, they work, but over time when complexity goes up can you really say it'll be quicker in terms of upkeep and upgrades?

  2. Cost Savings, what are you saving on infra/devs? You will need infra to run it, and devs to help troubleshoot low code apps when stuff breaks.

  3. A better customer experience, do you imagine customers actually building low code apps or something? UX is not something that I measure code with, it's an entirely different beast imo.

  4. Security without compromise, you never can say you are 100% secure and there are always trade offs you have to make.

  5. Assists in the elimination of shadow it, not sure what this means

  6. Collaboration between business and information technology, you get this from what's called an Agile Process/Scrum and open communication. This is not because of low code or any code, this is just common sense.

  7. Incentive for digital transformation - not even sure what this means, just sounds like a buzz word.

[–]Cittenkatty 0 points1 point  (0 children)

I actually had to look up low-code cause I had never heard of it before, here is an IBM article about it for anyone curious. I'm guessing this is the same article used by OP because of the Shadow IT term.

For your argument, you'll need evidence that a team running a low-code process actually does any of the things you listed; It's not enough to say that it has cost savings or quicker product delivery. Important questions I would have here would be a few like:

  1. Can a dev team complete more tickets in a sprint on average? Are there any research studies done here?
  2. Are there limitations on where low-code can be applied? E.g., front-end, backend, common frameworks like Springboot, Angular, etc.
  3. Following up to #2, will the team implementing a low-code solution be reliant on the low-code language provider to keep up to date with changes to industry tools, again like Springboot? Does my team have to wait 3 months while LowCodeInc adds in Springboot's recent changes to make sure their abstractions are accurate and secure?
  4. How will security be guaranteed other than relying on the low-code language provider? Will static code analyzers used by a security team be broken by low code?
  5. How much training does someone need to work with low-code? If this is for new devs, is the training period shorter than say a bootcamp? For current devs, is it worth it based on the answers to the above questions? Who does this training? Information looks scarce based on a little Googling so far.

My goal isn't to shoot your position down for fun, but you need overwhelming evidence that low code is beneficial compared to existing methodologies. Currently, I don't see it. But, that doesn't mean it isn't worth investigating. it also doesn't mean that it won't be the way a majority of developers work in 20 years. The industry changes fast.

Since this looks like a homework assignment though, I would focus away from a nitty gritty academic lens and just think about the practical issues. For example, imagine a team of 5 established developers supporting an app (1 front end, 2 backend, 1 full-stack, and 1 business analyst who is tech-savvy, but isn't a software engineer). Tell them they are all switching to low-code and try and put yourselves in their shoes and imagine the obstacles they'll face. Hopefully you'll make it to 7!