4 ms·

> Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a

> Some codeless solutions version control behind the scenes, but testing and regressions are not really part of what the end user thinks about. Again, this is a question of maintainability and scale. Small companies may not need the overhead. Until they grow and suddenly they do. Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales? As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.

fragmede 7y ago
When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs. What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper. Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product. Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.
- laminar 7y ago
  Thank you, that helped me understand the point much more clearly. It sounds like a cogent example of 'technical debt'; I'm aware of several software products that have tried to expand their capabilities by purchasing others' source code and have eventually run into similar roadblocks.

fragmede 7y ago

When a program becomes sufficiently complex, it's impossible to make changes to a program without the change affecting other parts of the program. Without tests, whether manual or automated, it's hard to know if a change has caused old bugs to reappear, or introduced new bugs. What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper. Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product. Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.

laminar 7y ago
Thank you, that helped me understand the point much more clearly. It sounds like a cogent example of 'technical debt'; I'm aware of several software products that have tried to expand their capabilities by purchasing others' source code and have eventually run into similar roadblocks.