|
|
|
|
|
|
by Timot05
871 days ago
|
|
|
Thanks for your detailed answer! Tons of information in there. To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits: - you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of changes. - If someone actually does want to pickup your design and wants to contribute to it, code makes it easier for them because more information is captured in the code, so they get a better sense of what the design requirements are. To your last point, we don't really see the code becoming the documentation of the implementation of the module. Actually the goal is to do something similar to the IC space or the software space, where the code becomes the implementation of something but the documentation lives somewhere else, perhaps in a datasheet-like document. Currently the schematic forces you to have both the documentation and the implementation baked into the same document, which forces you to find a middle ground between adding information relevant to those two objectives. |
|
|
I don't think this a fundamental exclusive benefit of "code" (ie text). I am skeptical how textual merging, especially default automated, can be applied in this domain except in trivial ways. This is a usually easy sell for software because you can structure your system to localize effects (even if there it isn't perfect). The big guns have very sophisticated workflow and tooling for this.
https://www.altium.com/documentation/altium-designer/collabo...
https://www.altium.com/documentation/altium-designer/using-v...
> code makes it easier for them because more information is captured in the code
I sincerely don't understand. Perhaps it is informative to consider that SPICE has been around for 50 years. The idea of using textual description for circuit design is not new at all, and they are used when appropriate. One must ask why the basic workflow is the way it is when the alternatives have always been possible.
> Currently the schematic forces you to have both the documentation and the implementation baked into the same document
Not entirely onboard with this forcing assertion, but is this necessarily a bad thing? https://en.wikipedia.org/wiki/Literate_programming