Workspace bridges the divide between architects and developers...

It combines specs created by architects in Studio with the details of the current code-base, to create a simple but powerful interactive visualization called the Structure Map.

It takes you right to any Spec violation (and other structural problems), highlights any new problems, and lets you navigate both ways between the code and the Structure Map via a Connector plugin to your IDE/editor. It is an excellent way to simply check and browse dependencies before starting into the development of a new feature.

In short, Workspace lets developers understand the details of the codebase through the project architecture.

It is normally hard for programmers to understand and maintain the high-level architecture of a code-base. This is because an “architecture” explains and constrains the relationships between large aggregates of code - but programmers mostly focus on a few lines of source at a time. Architectural descriptions are often abstract and too removed from the source code to be of real help to programmers, while the source itself is too detailed for understanding the big picture.

The nearest thing to a holistic view of the code-base for programmers is perhaps the project explorer within their IDE or source editor. This shows the hierarchical organization of the source, but it conveys nothing of the actual or desired inter-module/package relationships. It is also not easy for programmers to keep track of where in the big picture they are working, as they chase references from file to file.

This is a big problem. It is ultimately individual lines of code that make or break an architecture, and a well-defined architecture is supposed help a team to evolve a product faster, with less complexity and wasted effort. Only a programmer armed with good structural awareness can stand up to the strong forces of entropy, the drift towards disorder, the big ball of mud.

This is where Workspace helps, by making it easy for developers to understand a code-base from the weeds to the treetops – to see just the structural detail that relates to the source items they are editing right now (like dependent files, functions, classes, members, etc.), but in the context of the bigger picture (packages etc.). It also encourages the team evolve an agreed structural spec for their project, that keeps everyone rowing in the same direction, making ongoing development that much easier for current and future team members.