Limitations of QuickBase - Things that Cannot Be Done Natively

I agree! That was kind of my point in saying 5 to 10 years. Everyone has different needs and different priorities. If it takes them that long, clearly their priorities are not aligned with mine, and if enough of us engaged users don't like that and let them know, then they hopefully can realign their priorities with ours. After all, we are the customers.

If I wanted to be a coder, I probably wouldn't have chosen QuickBase as my app building platform. The fact that I did means I really don't want to lead with code. It has its place, but I would argue that if you are constantly needing to implement things in QB with code as a first choice, you are missing out on the biggest strength of QB, which is that it doesn't require coding for 85+% of what we all need to get things done. I've been a coder for 39 years of my life and I see all too often the great expense of code, especially when a small business has changes in its personnel, and the new people don't want to touch the old code. This is a problem everywhere in the business world, and one of the biggest reasons why I chose QB. I don't want to get hit by the bus and have our CEO cursing me under his breath every time he has issues going forward with someone's old F*&%ing code. So, in my opinion, better to not code unless absolutely necessary.

Dan, you are clearly a brilliant guy and a great resource to this forum. But most of your responses to these questions read like you are fighting a current by swimming upstream. It's not pragmatic or even desired by the vast majority of QB administrators to add gobs of code to their apps to get basic functionality to work. Sometimes it's absolutely necessary and appropriate. But that shouldn't be the rule. That's what we are all fighting for with our UserVoice suggestions. Coding can be fun, but nobody wants to support it later, especially when it's been written by someone else who understands it a lot more deeply.

Code can be implemented quickly by someone like you who really knows what they are doing, but its cost of maintenance and support over its lifetime will consume way more time than 5 to 10 minutes. That's why I want a robust platform that doesn't require me to code for every little thing. I think that is basically QB's mission. Why do you seem to be fighting that?

I'm sincerely asking this in a very respectful way. You are a great resource, but you seem to have an attitude about people wanting to do things simply without code. Creating code is simple, especially for someone like you, but it is indeed not simple at all to support it indefinitely. That's its achilles heel.

In today's world "coding" is an essential skill as essential as reading and writing. The backlog of features AK enumerated will still be here years to come as the current product development pipeline (including intaking and prioritizing suggestions via UserVoice) leaves so many requested features on the cutting room floor.

What do you think you are doing when you write formulas? It is "coding" albeit at more simplistic level. You are simply not going to benefit from the bounty of features that are flooding into your browser without using coding (mainly script).

I work for a small business, and I am the single resource for creating and supporting our QB app on which we run our entire company. The big issue for small business is cost. Not just direct costs but all costs. Above all, the skill that affords the highest degree of success in my environment is pragmatism. I weigh all the costs of every decision I make, not just how much time it will take me to bang out a working app today. Having said that, I don't want to reinvent the wheel. I'd rather pay QB a nominal monthly fee to do the heavy lifting for me. If I wanted to lift heavily, I'd be working as a coder. I've done that for decades, but I'm tired of that and I just want to focus on making my business better and more profitable. As such, I think I am a very typical QB customer. The overhead costs of supporting code are staggering compared to the effort to create it. That is why I avoid it as a first choice for anything. QB helps me do that most of the time. I am addicted to the speed at which I can implement changes in our business processes on the QB platform without code. As soon as I think I need code for something, it causes me to pause and thoughtfully ask myself if it really is necessary.

Formulas in QB are very well encapsulated and quite different from Javascript which needs to bring in and reference different external libraries from different sources that will change to different version numbers and potentially break things as QB iterates its environment. I have purchased well-developed 3rd party code that has already broken, not due to anything the programmer did wrong but due to QB making changes that no longer played nice with the old code. That's complexity, and you don't get that when writing formulas directly in QB.

I'm not against code, but I am definitely against unnecessary complexity. As Joseph Tainter pointed out with regard to society and civilizations, complex systems tend to fail catastrophically. Same goes for applications. I've watched so many applications fail over the years due to being designed and implemented in overly-complex ways that usually involve way too much code. I'm not being an ideologue, I'm just trying to be pragmatic ... and profitable for the long-haul.

>Javascript which needs to bring in and reference different external libraries from different sources that will change to different version numbers and potentially break things as QB iterates its environment

This is much less true today than when you may have been an active programmer. Today the browsers are crammed with features that used to require libraries and the overwhelming trend is for this feature growth to continue at an increasing rate. Moreover, QuickBase itself has already loaded most of the libraries you would commonly use for some enhancement or has them defined as a AMD module you just require. Additionally, there are so many powerful abstractions available today in JacaScript, HTML and CSS and so many external APIs that you are just locking you self out of the benefits they bring if you do not avail youtself. Haven't you noticed how short most of code solutions are? That's because of the abstractions and conciseness they offer.

Check back in six months or a year and that list of things that QuickBase does not do natively will be substantially unchanged unless script is used for a solution.

Michael I am grateful for your comments and lending the support.  I agree with you on the lack of transparency on part of QB in terms of new initiatives and what makes up their development list.  

I fully agree with your comments on the need for a code free platform. I don't want to name here but I got into a situation when I resorted for a coded solution in my app and I ended up with half baked solution which I never used because I paid for that in advance in good faith.  This goes to explain how you place yourself at the whims of code creator.  

I should have mentioned in my original note about the lackadaisical QB support function that leaves much to be desired. By being based in Australia I have only 2 hour window to ask a question or receive an answer because this supposedly internationally used platform cannot afford to have 24 hours support desk. Sometimes it takes several days for me to get an answer.

I still don't receive my alerts or notifications on the day and time I want because I have to align these to US timings. I brought this to the attention of Director Development but to no avail. I still don't have time zoned option for other parts of Australia so the date time stamping is inaccurate for someone in Perth. 

I sincerely hope that QB takes these views into view constructively and gives us a action plan to address most issues.