Is anyone else struggling to manage custom code?

[DaveS]

I've been developing on Caspio for about a year... and have learned a lot along the way.  As I've learned, I realized that certain coding / naming standards would have really been helpful.  But now it seems risky to implement changes because there's no easy way to identify - for example - where a table name is used in a calculated field or calculated value.  

I've done some work to solve for this and am curious if anyone else:

a.) Has this challenge / issue

b.) Has solved it in creative ways

Thanks,

Dave

[vidierre]

Hi @DaveS, you are addressing one real big topic related to many (all?) low-code platforms: the low-code paradigm. I try to explain, but it will be not a quick socialmedia-style answer, because it is fundamental to get to the deep of this topic.

Quoting some sentences from CASPIO website itself:

• Create Custom Cloud Applications Fast
• Low code accelerates the software production timeline
• With low code, business professionals and IT teams build custom apps that match their business processes.
• Low-code databases are a great solution for outdated systems built around MS Access and Excel spreadsheets
• Low-code platforms primarily enhance an IT team’s production
• Developers take advantage of low-code platforms to rapidly assemble software applications that would take exponentially more time if coded line-by-line. Programmers utilize low code’s pre-built app interfaces to bypass manual coding.

The great promise is speed and this promise is made to the developers, the programmers. It means that the developing methods and architectural knowledge are still needed.

• Which experienced developer has not be faced with the issue that to improve an app the whole data design should be scrapped?
• Which experienced developer has not be faced with the issue that to improve an app a big effort of reverse engineering has to be made because is not known (or is forgetted) how work the apps?

These aspects lead to the importance of the app documentation and the low-code platform knowledge.  None of you, maintaining or improving a CASPIO application, have ever asked yourself "did I do this in a trigger, in a formula field or in a formula in a datapage?".

Low-code doesn't mean low-design. The initial mantra in the low-code arena of "democratizing access to app development" is disappeared because "allow you to create applications without knowing programming" is the same of allow you to build or repair a blast furnace without having knowledge of metallurgy, you can blow up. Nowadays none remember the developer's mantra of '80 "to build a software do not start with coding, it is the last step to be done in order to verify what you have designed".  The big mistake is to believe that software develop is coding.

Your example to describe the difficulty: 

Quote

where a table name is used in a calculated field or calculated value

It is the main issues of all low-code platforms,  they have almost no-kind of support to the app documentation. But it is a very very old question of every software either coded or low-coded.

 In your post you describe another big lack in the low-code arena:

Quote

.... it seems risky to implement changes ...

The madness that comes out, on about all low-code platforms, is that after you deploy at incredible speed you app:
every change has to be developed on the production environment where your users work at your own risk
OR
you have to pay with money and time to build your development environment and move changes from it to production.

I know about customers that, after such considerations and facing the impossibility to improve their app or scale it without re-writing, have decided to swich back to a traditional coding approach.

At this point I have to make a loud and clear statement: this doesn't mean that low-code has to be avoided and I still consider CASPIO one of the best platform combining a right price and a solid set of capabilities useful for developers.

I can share with you my rule-of-thumb low-code developing methodology used to minimize these issues:

1.  The very first thing I want to know and clarify with my customers is the potential growth of the users number - very often I can set the proper customer's expectation in this phase. This set also my right attention during the app design. [this step is not low-code related]
2. Then I try to define the most complete set of use-cases - this is done with customer stakeholders and final users (or SME of final users) and I try to group with a logic such usecases. Together, but in a different document, I write down some requirements araising from discussions. This is the very first canva used to desing my app and the result is a two-section word document tha is the starting point of my documentation. [this step is not low-code related]
3. Then I use  the table section of caspio to build the data model - In this phase I do not define any datapage, trigger,  view and much less any front-end web page. This usually lead to write down a third section that includes all my doubts and questions for the customer. [this step has to be done with CASPIO and NOT with other data-design tools]
4. Using the relationship view I test use-cases of point 2 - this lead to add more questions to my 3rd sections and/or some data remodelling. Usually in this step I add my own use-cases that rise up from experience and from non-functional requirements. (how users has to be defined? a self-registration-flow is needed? there is the need of any state-machine to handle workflows? Is app log required? Is data auditing nedded? etc. )
5. Usually the first, of a neverending cycle, customer review take place - the goal is to address all issues listed in the 3rd section writing how or why I address it or discard it. In this step I try to make more consistent the grouping of use-cases.
6. The datapage developing start -  I start to shaping the needed datapages from one group of use case (and if necessary the webpages also). Generally the very first are not about the core use cases but rather from the non-functional requirements. In this step I build, with my own standard, a solid folder structure to avoid to be lost in the firther steps. This is one of the cornestone pieces of my documentation. [this step is CASPIO related]
7. The development travel - At this point I start to cycle from step 2. to 6. showing to customer results. In every cycle the step 6. growth also with front-end development and data model-refining. Only at this time I design some Views that could be necessary. When this end? Who can say?

The main issue to avoid: DO NOT SELL YOUR SPEED CAPABILITY TO CUSTOMER, let them to discover how speed are you, do not transform this strength in your cage!
I know it is a long answer, but your issue it's huge even if it can be said in few words....
PS I used my method also to revamp or migrate apps that someone else wrote.

[DaveS]

@vidierre,

I appreciate the thoughtful answer - it's fascinating.  I've got a pretty varied technical background.  I started my career doing programming and relational database design for a consulting firm in the early 1990's before doing a bunch of software company management (led services, product, engineering and even led a business unit of a public enterprise software company).

I went into Low Code with my eyes open on limitations.  My philosophy has been: If I get this thing off the ground and my biggest problem is scale, I'll have the $ to replatform it.   A year in, I still believe that.

I 100% agree with you that an architectural mindset is required.  But lack of understanding of Caspio in the early stages led to some mistakes.  There will be more...  I started developing and learned along the way - both from a CASPIO perspective and an application perspective - that I could have designed better or used different standards.  I also think the "where did I implement that function" problem (trigger, task, data page, webhook) is universal and not at all unique to Low Code.

I'm curious about your comment about users and scalability...  That's a complete mystery to me.  I know that Caspio is built on enterprise class sql and aws...  My use case is not high intensity, but I do feel like I'm flying blind in that area.  Any rules of thumb that you've found helpful?  

Regarding custom code management...  I'm looking at building a utility to extract the custom code from Caspio so that I can - for example - find all the places that a table or column is referenced in custom SQL.  

I'd love to stay in touch with anyone who's approaching LowCode with an enterprise mindset.  I think that Caspio and others are underestimating the opportunity of solving some of these enterprise-class problems.... and I don't think they are impossible.