7 ms·

Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatical

Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatically I too have seen them getting jobs done. I'd also wager it will not cost more to rewrite it, especially if you deeply discount the non-developer resources that were used to create it (often salaried employees' time, and even then those individuals likely came out ahead compared to the tedium of doing it manually). Consider it a prototype. Also, the functional spec of "do exactly what the domain expert made this convoluted Excel spreadsheet do for the last 2 years, but with better validation of inputs" is often far more accurate than some daydreamed RFQ. The part that confuses me is why this makes sense as a separate enterprise product. Had the original author been interested in learning a new tool, they'd have probably been better off starting with Python. I recognize that non-developers are silently building their own tools, some of which will be a hit and later need replacement by developers, but are there really sales teams going around to big enterprises suggesting that they buy licenses for all their employees to be able to build their own tools using their particular low-code solution that will eventually be replaced? Seems like a difficult thing to sell IMO...

nightski 5y ago
Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.
- Spooky23 5y ago
  Usually significant low code stuff is more reflective of organizational politics than anything else. Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.
tolstoshev 5y ago
On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.
bigger_cheese 5y ago
In the last 6 Months my workplace has started heavily using Power Apps. The first impression I got was 'holy crap, this is MS Access on steroids'. My workplace heavily(ab)used Access in the 90's and we got bitten very badly when support for Access was discontinued. We also had a lot of VB6 code which was similarly orphaned. In the mid 2000's someone in our IT department decided all new business apps were to be written in Java I believe this decision was made partially as a reaction to what happened with Access and VB6. The result was everything stagnated our in house apps became massively bloated, buggy and almost no one did anything 'to fix things. Any changes had to go through external contractors because no one knew Java or how to support these apps. If they had mandated Python like the post I'm replying to suggested I am sure the results would have been the same. Probably worse because harder to find cheap contractors to work on business apps in Python. You are not going to get HR people, you are not going to get Finance Accountants, you are not going to get commercial team or legal to learn a full on programming language. That is why these products have such a niche in large Enterprise orgs. Yes you get buggy monstrosities but you can also very rapidly develop working tools that solve real business problems. I think what makes Power Apps attractive is the whole Azure ecosystem Microsoft have built around it. There is a whole suite of tools that all talk to the same common backends, Power Automate, Azure Databricks, Azure ML, Power BI, Power Apps etc. From what I've experienced as all of this stuff has been rapidly rolled out across my org is it all "just works" and seemingly solves real problems. My real fear is that 5 years down the line it will have all be abandoned and we'll be left with MS Access 2.0 and a bunched of orphaned unsupported apps again. I hope Microsoft have learned from what happened with Access but at the moment it remains to be seen.

nightski 5y ago

Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.

Spooky23 5y ago
Usually significant low code stuff is more reflective of organizational politics than anything else. Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.

tolstoshev 5y ago

On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.

bigger_cheese 5y ago

In the last 6 Months my workplace has started heavily using Power Apps. The first impression I got was 'holy crap, this is MS Access on steroids'. My workplace heavily(ab)used Access in the 90's and we got bitten very badly when support for Access was discontinued. We also had a lot of VB6 code which was similarly orphaned. In the mid 2000's someone in our IT department decided all new business apps were to be written in Java I believe this decision was made partially as a reaction to what happened with Access and VB6. The result was everything stagnated our in house apps became massively bloated, buggy and almost no one did anything 'to fix things. Any changes had to go through external contractors because no one knew Java or how to support these apps. If they had mandated Python like the post I'm replying to suggested I am sure the results would have been the same. Probably worse because harder to find cheap contractors to work on business apps in Python. You are not going to get HR people, you are not going to get Finance Accountants, you are not going to get commercial team or legal to learn a full on programming language. That is why these products have such a niche in large Enterprise orgs. Yes you get buggy monstrosities but you can also very rapidly develop working tools that solve real business problems. I think what makes Power Apps attractive is the whole Azure ecosystem Microsoft have built around it. There is a whole suite of tools that all talk to the same common backends, Power Automate, Azure Databricks, Azure ML, Power BI, Power Apps etc. From what I've experienced as all of this stuff has been rapidly rolled out across my org is it all "just works" and seemingly solves real problems. My real fear is that 5 years down the line it will have all be abandoned and we'll be left with MS Access 2.0 and a bunched of orphaned unsupported apps again. I hope Microsoft have learned from what happened with Access but at the moment it remains to be seen.