If you have a small, well-organized architecture where you have a clear idea about which responsibilities are handled by which codebase, you may be working on a project where someone has already separated responsibilities in a clear, maintainable manner. Or you may have enough context or tribal knowledge about the product to get by without it. Marmot may not be the tool for you.
The rest of us often find ourselves learning how to take care of someone else's creation. The drive for features, growth of the team, and other organizational issues can cause a product's architecture to take on a life of its own. Developers new to a product often walk into an architecture that has outgrown the simplicity of its earliest stages of development, leaving one to wonder:
- "Just how is anyone on the team supposed to see the big picture?"
- "Is there even anyone [left] on the team, who can?"
If this sounds familiar to you, give Marmot a try. It might just help.