DISCUSSION: What are most common mistakes you see in larger Coda implementations?

1

If you are a consultant walking into existing large Coda implementations . . . what kinds of things make you shake your head . . .? Or things that make you want to rip it out and start over.

6 Likes
2

Interesting topic. Here are some that come to mind for me. Interested to see what others have to say!

  1. Massive tables using select lists within the table, rather than lookup tables, and having duplicate information in multiple tables.
  2. Unrelated workflows all in one doc. For example, when people have their financial workflows in the same doc as their project management workflows.
  3. Not taking advantage of Doc Locking when there are many people working in a doc
  4. Having sensitive information in hidden pages instead of a separate doc
7 Likes
3

Great question!

I have made the mistake before of creating many little docs for different purposes and then having to join them because they shared information.

It did help keep things manageable at first to keep things modular though.

Looking forward to responses from more experienced consultants.

4

Oh boy. Don’t get me started on that.

  1. Messed up table structure: people coming from Sheets love using columns as data entries (e.g. 2021 Sales, 2022 Sales etc) while those should be denormalized into rows on a separate table.

  2. Messed up data in cells: phone numbers and emails with comment text right in those cells (obviously copied from Sheets like that) e.g. “+1XXXXX (assistant)”; mixed row relations, @-references, and plain text in Relation columns, and alike.

  3. Lots of separate tables for the same thing, e.g. multiple Notes tables. Especially this became bad when Canvases got added: sometimes there are 100+ rows with canvases, and each canvas has its own set of base tables like Notes, Meetings, Contacts etc instead of using views.

  4. Company-wide docs created and packs installed by many different people: it’s hard to pinpoint who’s the owner of what, and whose connection is used for which sync table. It’s just a mess that way, and a time bomb waiting to go off when one of those people leaves the company.

  5. Messed up single- and multi-select references because people don’t know they should Filter().First() when they expect a single result.

  6. Massive amounts of named page formulas dependent on other page formulas — I made a video on that.

  7. Having base tables all over the doc — I made a video on that

  8. Excel-like formulas: almost always using nested syntax and not chained, and using Or(x, y), And(x, y) etc functions instead of their x OR y x AND y operator counterparts — also talked about that.

  9. Badly engineered formulas that do a lot of redundant calculations or do them in an inefficient way and hence are very slow.

  10. All that @Kayla_Jett_Taras said.

That’s just from the top of my head

7 Likes
5

This would make an AWESOME YT video series @Paul_Danyliuk

1 Like
6

Blockquote 1. Badly engineered formulas that do a lot of redundant calculations or do them in an inefficient way and hence are very slow.

Do you recommend a good resource to learn about how to write properly engineered formulas?

7

codatricks.com and youtube.com/@codatricks, eventually :slight_smile:

Other than that, there’s no much about CFL performance. This article is a good entry but it only barely scratches the surface (and not all advice is the best in all circumstances)

To get the fundamental understanding, you have to take a course on algorithms in general computer science. It will teach you how to optimize your formulas, but it’s a long way: it’ll basically teach you programming first :slight_smile: One day I’ll make something like that but specifically for Coda.

1 Like
8

If I may, what constitutes a “large” Coda implementation in your mind?

9

The “one big table” idea drives me nuts. I find that if it’s someone with no development experience, they think of Coda as more of a spreadsheet and they don’t build any relations into their table structures. First thing I do is try to normalize their data as much as possible. The second would be formulas. The average non coder person doesn’t build formulas very well.

1 Like
10

Hi Susan,

My approach will drive you around the bend… :stuck_out_tongue_winking_eye:

But it is for a very specific user case, knowledge management kind of scenarios.

At work I have a single doc, with 90% of information in a single table called dbThoughts. At the heart of the structure of this table are a few columns: thought type, two cross-reference columns and a canvas columns.

The canvas column selects a boilerplate based on the thought type. If the thought type is “functional design document” the canvas column is pulls in the FDD boilerplate. If the thought type is a form, report, interface or some other development, the canvas column will pull in the boilerplate for FRICEW.

The cross-reference columns at its simplest allows for a freely defined zettlekasten implementation. But it also allows structure by linking the FDD to the FRICEWs that were programmed to implement the FDD.

The next logical evolution was to add start and end date columns to these design items. But it always takes several actions to implement anything non-trivial. SO, thought type action items come in, with a column for Project.

Now I have the ability to create timeline views for projects, with milestones, dependencies etc.

As the work gets implemented, I create entries of thought type How-to. This is for the end users, and the support staff that explains how to use and maintain the functionality. With Cross-references to the above-mentioned design documents.

And all still in a single table, which means that you can use table search to get hold of ANYTHING in that table.

But it’s just a ramble…
Rambling Pete.

1 Like
11

Still on the topic of table design, I work in SAP, and had for the last 25+ years.

The original R/3 design, later repackaged as ECC, had something like 11 tables for financial information: header and line item, financial accounting, management accounting, assets, project and profitability analysis. This is for the OLTP data. Then everything was transferred to another set of physical hardware for OLAP.

15 years ago, SAP introduced HANA, which is a columnar RAM based database management system. Now there is a single table, which is used for both OLTP and OLAP.

Extremely simplified, SAP finance is now a massive pivot table…

New tools enable radically different designs.

Just another ramble… :wink:

12

For something like that one big table makes sense. I keep one table called notes and then I just put everything in it with “tags”. And when I have some To Do item that I have a lot of information on, I have a button that can move that To Do Item into the Notes table so I can keep that information if I ever need to reference it.

I’ve never heard of zettlekasten. Had to look that one up. Now I have some reading to do to figure out how that works. :slight_smile:

1 Like
13

i find that makers who have no training in database design or ux design, often hit a wall that limits the amount of complexity they can handle in building solutions.

its not a limitation in the nocode tool, but in their ability to organise their thoughts, ideas, user requirements, next steps and the overall flow of the user experience. they are unable to articulate to themselves or to others the structure of the solution.

even a rudementry understanding of these topics seems to remove this barrier.

so i am building a framework to provide these insights (and also an understanding of agentic workflows).

the beta program for this framework kicks off next week, and i am looking for makers who feel they could benefit from this, to help me refine and develop it further. (pm me if intetested).

max

4 Likes
14

Great topic Troy!

Building on some of the other points here:

  1. Building one “SuperDoc” that everything cross-docs into, leading to massive performance issues over time.

  2. Using undocumented formulas like ParseJson and Button to build functionality without the benefit of the many elegant patterns the community has refined over time.

  3. A lack of understanding of WithName leading to very large filter formulas.

Generally, when trying to use Coda as a System of Record tool for some process like Project Management, CRM, or Inventory Management there’s still significant limitations to build around - especially with Pack tables. If you haven’t had a few years working those problems, it’s easy to build your way to a 200+ formula column table + slew of automations that just break as the doc slows down.

15

That’s intriguing @Brian_Sowards . I’ve definitely had a couple of really wide tables, though not that wide. A few questions I’d love to pick your brain on:

  • How would you describe, in general, the source of this problem?
  • What would you say is the general solution or mindset shift necessary to overcome this?
  • How about specific tips?
16

Great questions Alberto!

  1. Generally it’s trying to enable users to take actions like mark a task as “Blocked” or a sales deal as “Closed” with some added functionality (like updating other columns). I’ve also seen a fair amount of this in trying to provider a way to sort nested information against a couple factors (Priority, Status, Due Date, etc.).

  2. First and foremost - look for solutions to these common challenges here on the Community forum! These are common Coda challenges (you can find posts back to 2019 on the topics) and there are elegant solutions now.

  3. Specific Tips:

Linking to a specific view for a row: Link to a personal view of a row's content in confirmation email

Learn how to use WithName(): Launched: Reuse logic and create nested loops with the new WithName() formula

and you’ve inspired me to write up some posts on a few more, thanks Alberto!

17

I’m definitely interested!

1 Like
18

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.