The first time I read that post I was fairly new to professional programming, so my reaction was docile; “Sounds good” I thought to myself, and figuratively nodded in agreement.
Reading it once more I found that I still agree with the case but my reaction also came with some refinements that I think should be made.
Uncle Bob’s points
In Screaming Architecture, Uncle Bob argues:
- Application architecture should represent the “what” rather than “how”.
- Frameworks should not dictate the application’s architecture.
- Application architecture should be testable regardless of the frameworks you’ve chosen.
But I think that by rejecting the involvement of frameworks in our architecture we may also reject positive additions such as:
- Higher speed of development.
- Reduced boilerplate code.
- Reduced responsibilities.
I think there are times when the benefits of a framework outweighs its “lock-in”s; these benefits could reduce the developer’s workload while conserving the organization’s resources so the framework should be considered by the architect as a valid possibility.
An example I like to give in this case is my “Mac vs. Linux” argument (no flame-war intended).
To put it simply and somewhat inaccurately, I view Linux as “free” and Mac as “comfortable“; each has its own pros and cons.
I trade comfort and in return I get freedom
On my development machine I run Linux and I wouldn’t dream of developing on a machine that runs anything else because I love and need the freedom it provides; in my case, it’s well worth the time I spend on maintenance, troubleshooting and configuration.
I trade freedom and in return I get comfort
At home I could set up a system aimed at media consumption and would easily go with Mac because the setup, configuration and decision making have already been done for me; that’s fine because my goal is quick and easy media consumption.
Bring it on home
So your project probably “screams” Grails and is now forever locked in with Grails, but you’ve saved a huge amount of time on coding and configuration.
I definitely believe there are cases in which “comfortable” architecture pays off and I believe it’s the responsibility of the pragmatic tech-lead to argue for it.