MicroObjects is a fantastic way to write OO code. There's very few pain points that I've encountered. The teams using MicroObjects deploy confidently and have near zero bugs. New functionality and features are quick and easy to implement.
The practice is vastly different than how most people write code. Most TRY to employ known best practices, when they can. MicroObjects is the discipline of applying these practices, always. There's never a, "It's really hard to do here, so we won't here". If it's hard - the system needs to emerge some new architecture to support what we want to do. The code is ours - we aren't beholden to past decisions - we can make the change to make our job easier.
When I give talks about MicroObejcts, the attendees get hung up on the "to the extreme" part of the practice. There's not a lot of conversation around "why no getters", but it focuses on "that'll be a lot of files" and "how do you handle naming".
These are things I'll address earlier when I get back to presentations on MicroObjects, for now, a transition. My presentation is going to be about why I do MicroObjects - Maintainable Code.
I posted on twitter recently that I submitted a talk, "Technical Practices for Highly Maintainable Code", which is the new talk I'll be giving. It's 90% the same content. I just won't be as upfront about taking these practices all the way. I won't shy away from it, maybe it'll come up. With "Technical Practices" as the focus of the talk, I can shift from talking about the aspects of MicroObjects you'll NEVER SEE until you understand and apply the technical practices and keep it focused on, "Let's do these practices".
MicroObjects are here to stay.
I'm not going to change how I code, or how I promote others coding - it's just that you can't do MicroObjects style without understanding the technical practices first. One you start to use the practices, then it'll be about taking them to the extreme.
Basically, I gotta help our industry with some 100/200 level classes before I work with them on the 300/400 level concepts.
Now I gotta figure out some training around these concepts, get to actually TRAIN people in them; and then as they apply the practices until they can't apply them any more... They will have MicroObjects.
MicroObjects are nothing more than well known best practices strictly and consistently applied.
The mass majority of the industry just doesn't know how to apply them - so I need to shift gears and work to have the focus on understanding the technical practices; not the effects of taking them to the extreme.
My presentations are now going to be reflecting this. It's about the Technical Practices for Highly Maintainable Code - we'll talk about how to handle the effects of it once you hit them.
This is clearly something that's been brewing for me for a while. The shift as a focus on "Technical Practices". A chunk of my posts recently have all been "Technical Practices : X" titled.
I've kinda been recognizing it, but it took a conference where someone else presented the same kinda topic in a different way that demonstrated the value in a shift of focus. Really pinged that for me.
I'm trying this in an effort to help engineers be better. If I can get better discussions going by dropping the long term goal/effect to discuss the hands-on-keyboard activities, I think it'll be more effective.
It's good to run experiments.