Story Siloed Architecture

Intro

Imagine implementing user stories as independent modules within an application.

• What if we could implement each user story in complete isolation from the other user stories within our application?
• What if we could test each user story in complete isolation from the other user stories within our application?
• What if we could rewrite an implementation of a user story without any affects to the behavior of existing features within our application?
• What if we could examine code coverage per implemented user story?
• What if we could examine the maintainability of each implemented user story?
• What if there were a framework in place where talented engineers could really lead by example?

User Stories as Silos

Silo: a system, process, department, etc. that operates in isolation from others:

I am a disciple of Martin’s teachings. As a result, I decided to implement my interpretation of his Clean Architecture idea. I built Quote Builder three years ago and tried my hardest to conform to Microsoft’s user experience guidelines for their Metro design. That resulted in a third of the app’s ratings being one-star.

The client architecture of that version is below:

The Clean Architecture approach that I built with Xamarin.Forms is the following:

A user-story module within the architecture is as follows:

The Solution Explorer for the Windows Store app looks like the following:

The Solution Explorer for Xamarin.Forms app looks like the following:

The following table reflects code analysis results of the application including user story modules:

Retrospective on Story Siloed Architecture

When I rewrote Quote Builder for Xamarin.Forms, I created a project per user story. I also created a unit test project per user story. This resulted in about 45 projects within my solution. Thus, this gave me long load times (approximately 15 seconds) when opening the solution in Visual Studio 2015. I also found myself waiting for half a minute each time I would build my solution. As a result, I consolidated my unit test projects to just one project which reduced load-time by a third.

Teams implementing Story Siloed Architecture, need to respond to the organic growth of the software over time in which the application becomes proliferated with projects that take will eventually take a toll on a solution’s load-time and build processes. There are workarounds though. For example, multiple projects can be consolidated to one project based on the related concerns of user story modules. In addition, other solutions can be created per related set of modules. This will enable a solution to replace project dependencies with DLLs. Performing this substitution will reduce the time to load a solution, build it, and execute unit tests by orders of magnitude faster than relying on only projects.

I also like the side-effect of isolating user story modules. Hence, this architecture reduces the likelihood for the codebase to experience entropy. For example, the isolation of each user story module enables code analysis to be utilized more effectively. Hence we can now scrutinize each user story’s implementation which (because of this architecture) is now in complete isolation of other user stories. For example, we can now examine the maintainability index and code coverage from unit tests targeting a specific user story module. Thus, isolating user stories into independent modules for developers to pull from, will encourage developers to finally acknowledge ownership of their code’s quality because no other developer will modify their module without the owner’s review and approval. Another benefit is that user story modules that were poorly implemented can now be refactored or in some cases rewritten without having to rewrite a significant portion of the application. Also, developers that do hold themselves accountable for the quality of their code are  now enabled to lead by example. Hence, because their user story is isolated from the modules that other developers are tasked with, quality focused developers can now own the quality of their story and demonstrate how to write solid code with outstanding code coverage which other developers can reference and learn from.

I am not convinced that implementing Story Siloed Architecture is worth the overhead for a single developer project. I do believe that this practice will encourage developers to be more surgical when it comes to maintaining an application’s architecture due to isolated user story responsibilities.

In addition, I do believe that clean architecture makes software more maintainable over the long run. Developers can now zero-in on a user story module that’s most likely to host a reported bug. It also compliments Visual Studio’s CodeMap so that maintainers can identify dependencies of specific user-stories as the user-story module diagram conveyed.

Conclusion

In conclusion, I ported a Windows Store app to Xamarin.Forms using Story Siloed Architecture. I provided disclaimers about using this approach in regards to load-times with Visual Studio solutions and what can be done to resolve those concerns. I also identified the benefits of leveraging this pattern in regards to refactoring or rewriting a user story module as well as the increase in code quality.

NOTE:

Scott Nimrod is fascinated with Software Craftsmanship.

He loves responding to feedback and encourages people to share his articles.

He can be reached at scott.nimrod @ bizmonger.net