I’ve been happily using Coda for a couple of months now but I’m at the point where I have several new use cases that I am trying to implement.
However, I’ve spent the last couple of hours researching the things I need, and I’m constantly finding threads on these forums where the features have not been implemented, with no visibility into priority by the dev team. Some of these are 3+ years old. Here are some examples:
The reason I highlight this is because all searches I ran lead to these types of stale threads and dead ends. None of the topics I searched for had an officially provided or recommended solution, but some did have a few brittle workarounds suggested. Generally I would hope to find at least one or two good solutions from so many research topics, and it’s concerning that I didn’t find any
Could it be that Coda is not the right tool for my use case?
Coda is a fun little program for people to play with who know next to nothing about data. Promoted by nice people for sure, it’s got its place. But if you are serious about data management, it’s just a toy.
And based on these nothing burger updates they keep offering, I can’t see how that’s going to change anytime soon.
What do you mean with data management?
What are some things that you think is necessary?
What do you think is the goal of a cod a doc?
I think my particular use case is best described as “Project management and task tracking for a software engineering project”
Birds-eye views such as “outline”, with native support for relations/hierarchy is essential
Syntax highlighting is also important for a software engineering project where snippets of code are to be socialized within the team
Lack of markdown support is a big letdown, given how many users are asking for it, and how easy it would be to implement. Based on this alone, I’d go out on a limb and say that there must be issues with the development methodologies at Coda.
For example - Product Owners who may be hoarding engineering resources for their specific user stories, and leaving little or nil bandwidth for Engineering to tackle areas that:
(a) do not have a specific Product Owner; or
(b) are trivial to implement, but have been left to age for 3 or more years due to low priority
Let me from a user perspective come up for the Codans:
Remember that the basic design for Coda is to be adoC. An extremely flexible doc. But it is not a project management tool. (Although many, many people have used it as a project management tool of some sort.)
Which include me. I use it extensively on my SAP project implementations. I manage the acquiring of the gap details, designing the solution, managing config gathering and other documents over multiple roll-outs, to do lists, and much more.
What Coda has provided so far is a very solid basic, but expandable platform. With the upcoming pack developments, it will be possible to modify various areas of the system, including formulas and adding new column types to tables.
Then it seems the marketing material and tutorials should be updated to reflect this.
Apologies for being so forward - but I do think it’s disingenuous to market Coda using dedicated project management features (assignments, roadmaps, etc), but then when Coda does not keep up with the needs of its project management users, it is insincere to suddenly claim Coda is not to be used in those ways.
Putting that aside, it still does not explain the lack of markdown and syntax support - features that should certainly be in “adoC”
In addition, threads should not be left open for over 3 years with no indication from Coda regarding priority, or whether the requested features are outside the scope of the tool. There needs to be improved visibility into product priorities (such as a public roadmap), and when requests will not be taken under consideration, ensure to clearly state so, and close the thread.
In summary, this has been a fairly enlightening couple of days. I can see now that Coda is not the right tool for my use case any longer, and the most appropriate tool for me is JIRA.
Let me give you an analogy:
Koos calls for an accounting package. Quickbooks volunteers and says we have an accounting package. Then later Koos discovers SAP’s S4/HANA, with memory based storage, different GL ledgers to record different Accounting principles, and the Material Ledger to record material purchases and manufacturing at the actual cost.
Koos is not justified to judge Quickbooks as not an accounting package, nor it’s employees of using sub-standard methodolgies.
It simply means Koos has found a product better suited to his needs.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.