4 ms·
this may work well for teams of 2-5, I simply don't see this working at all for any larger teams or any team with formal development processes. The whole idea
by dirkg 5y ago
this may work well for teams of 2-5, I simply don't see this working at all for any larger teams or any team with formal development processes.
The whole idea of merges/PRs etc is to be able to formalize this stuff, track it, keep history etc in a way that is open and can be used with multiple tools.
Using some kind of proprietary, or even open source, web backend SaaS completely defeats this.
And the whole 'real time google docs for code' is going to be incredibly intrusive for most experienced devs. People dont make a habit of micro inspecting every line of code someone writes, no one has the time for that. The whole idea is to have good design practices, unit tests, CI/CD etc, good APIs and interfaces.
Sturdy sounds great for small startups who are all basically working on a single shared file and everyone is doing some sort of massive pair programming. That simply doesnt work for other models and is a nightmare. Learning git (or any other vcs) is a tiny tiny part of software development, its not a barrier like its being presented unless you are a junior dev starting out.
- videlov 5y agoThanks for sharing your perspective. I understand the point of formalizing contributions but wish to challenge the need to do so for every type of contribution. For instance changes that have low impact production (eg. clarifying documentation) are subject to the same process as high impact changes. We are experimenting with an idea where depending on configuration + heuristics (file, author, semantics of change) the formal review is skipped, recommended or enforced. Alternatively, permit deployment to staging environments without sign off. What we aim to achieve with the real-time design is create value that would not otherwise be possible. For example, making use of CI much more frequently. I have in the past made and pushed throwaway commits just to trigger CI and get feedback sooner. We have been using Sturdy in it's own development over the past 9 months. I'd say the workflow doesn't quite resemble pair programming. We check each other's work-in-progress occasionally and give code suggestions/comments whenever we can be helpful to one another.
- cutemonster 5y ago> We have been using Sturdy in it's own development I'm wondering, if one person has some edits in progress (which won't compile), and another person wants to compile and run the app, then, does s/he need to wait for the first one to be done editing?
- zegl 5y agoNope! Sturdy never syncs edits from one computer to another directly. Our analogy with Google Docs might be falling apart a bit here. We're working in separate workspaces (which you could equate to a branch), and are syncing and sharing the workspaces only when the code is in a good state.
- cutemonster 5y agoOk, and, a good state -- I'm thinking that means when there are no syntax errors -- I suppose that generally it's not feasible to compile and run all tests. One way to use Sturdy, that looks the most interesting to me currently, could be to onboard new team members -- maybe fixing some problem in their first contributions, while they see the fixes happen real time and can ask questions