One of the things I've noticed working with multiple devs doing microObjects is that the code generated tends towards a single style.
A module can be built in as many ways, or more, by a set of developers. To perform changes on a type of module you'll have to understand many different ways of doing it. The wide variety of implementations to do the same thing is going to decrease maintainability of the app.
If my writings on microObjects has shown one thing - decreasing the maintainability is to be avoided. If it's a practice that can be changed - change it.
In typical development, this is where the "architect" role plays a part - it defines the larger picture for each person to abide by. It limits the scope in ways. It doesn't drive developers to write pieces the same.
Code reviews, can help. By the time there's a code review, the modules pretty much done. If the "design" is a deviation it's either rewrite or suffer it. That's not true; it's going to be suffered.
Extreme Programming has Pair Programming and TDD to help development. I find these to start to minimize the span of designs that can exist. TDD limits the design options towards testability. Pair Programming incorporates multiple developers styles into the final result. Changing the pairs up helps spread the undocumented style to all the developers. It can easily vary and as code evolves... Convergent evolution leads to very different results. What ends up doing the same thing will be doing it very differently. We're back to decreased maintainability. While XP makes it easier and safer to refactor - It's still a hefty refactor of how things work.
All of these leave the code open to a lot of different implementations for the same type of behavior.
This is something that I have found microObjects to be really hard to do in, without explicitly trying.
When you have to do X steps, and each step is an object with that behavior... You kinda have the same objects, named pretty similar, Ordered pretty similarm Interacting pretty similar. Multiple developers produce the same style of code. The same patterns emerge and the same collaborators used.
The simpler your objects, the harder it is to have widely different implementations for the same behavior.
When I started with micrObjects, I created a simple test. Display a story title from HackerNews.
Procedurally this is about 15 lines of code, including using NewtonSoft to parse json.
I was fortunate to be spinning up a new project as the technical lead. I got to select the technical approach - I went microObjects.
There were two other engineers on the project, brand new to working with me and to the... well... brand new microObjects style.
I had all of us do the simple hackernews display, individually. No collaboration on it. I was explicitly looking for the code similiarities aspect. I was testing my theory.
Of course I practiced some microObjects with them first; to get them understanding at least the concepts to be applied.
When they were finished - it was almost identical. Which was almost identical as mine. Naming, some order, some microObjected better in some places.
The similarity was there.
Three engineers who had never worked together before, of very different experience levels. X years, 5X years, and 10x years of experience (where X was the newest developers experience).
I've never seen this range of developer experience produce the same design. A theory about microObjects got some great data that day. It allows developers across skill to produce very similar designs which allows any developer to work in it comfortably.
TDD starts to approach similar designs for smaller modules. Dependency Injection helps drive this. If it grows beyond a few classes of collaboration - TDD breaks down on driving similar implementations. It's intending testability and refactoring safety. It's this refactoring step that I find design can really start to deviate.
One of the drivers I've had in software development is, "How can developers produce similar code?" I realized early on that the vastly disparate styles developers produce makes maintaining code hard. It makes it so you have, "Bob's Code". And "Oh, Luis wrote that - He gets annoyed when others modify his code". This is detrimental to collective code ownership.
Even if we we don't mind others working in "the code we wrote" - Do they mind? Do they disagree with the design but have to work with in it?
I've reviewed a lot of modules and made a lot of comments on code reviews, basically questioning the design and calling out a lot of potential issues.
A team I did this on implemented design reviews before we could start coding so that we could hash our the design points brought up earlier in the process - where it's easier to fix.
It got a little BFUD for that module; but not bad for how we worked. It was also used to shut me down when it came to code review time, "this is the design we approved", even when I had strong disagreements with the design that was majority approved.
It improved the code overall.
The code reviews I almost singlehandedly forced on the team improved the code.
I found things to help the team improve the code. I was very happy to see this happening.
OK - Slight tangent about how I've been looking for ways to get developers to produce similar designs.
It's something I care about; and it's something that microObjects happens to do. Which is a part of why I enjoy it so much - Developers produce similar code!
They produce collaboration in similar fashions. Similar implementations of patterns fall into the code from different developers. The style restricts options in such a way that the style is almost forced.
While restrictions are a giant pain - The restrictions microObjects place produce more maintainable code.
With more maintainable code, you can produce value for the customer faster and better. Which is what we are paid to do. MicroObjects is a development style that allows us to do what we're paid to do faster and better.