Understanding the Tradeoffs
I have gone through a few different ideas of what I should be writing about this week. And here I sit on Saturday morning, still pondering the tradeoffs. Tradeoffs are, after all, at the heart of everything we do as Software Architects and Engineers. When we start a new project, well, we have to start somewhere. I would imagine that few people sit down and ponder whether they are going to use Ruby on Rails or Play Framework or CodeIgniter. We’re going to go with what we know and have used in the past, and occasionally we’ll go out and find something new to add to our architectural toolkits. The next generation of frameworks will hopefully address the shortcomings of its predecessors.
I want to get into more details about how we built Pirc.com, but I keep feeling drawn back to the question of why we built it the way we built it. Why did we build it using Play Framework, when Ruby on Rails seems to be the de facto standard? Why are the controllers written in Java while the business logic is written in Scala? And why bother modeling the domain with interfaces?
My friend and editor Nathan Dintenfass put this to me as a question of intrinsic vs. idiomatic architecture decisions. He also talked me down from the ledge of “Rails is bad and here’s why”. His advice to me is that our choice of programming language does not protect us from writing bad code. Our choice for framework does not preclude us from creating a big ball of mud.
Idiomatic Architecture Choices
Frameworks are typically born out of the observation that when building a new system from the ground up there are certain things that we find ourselves doing over and over again. It’s fun the first couple of times, but after a while it just becomes tedious and potentially error prone to continue having to worry about minor variations on these same details. Any Software Engineer worth her salt is going to try to abstract that stuff out so that she can reuse it over and over again and not have to worry about it any more. This abstraction layer will attempt to impose some level of organization on the problem domain, giving users of the framework a natural place to include application-specific specializations on top of the abstract solution. MVC web frameworks, for example, make it as easy as possible to set up HTTP routes, controllers that serve those routes, and models and views for storing data and presenting results. And as anyone who was coding web applications in 1999 before those frameworks came to prominence can tell you, having all of this framework in place requiring only that application developers add their models, views, and controllers on top is a significant improvement over how we used to do things.
The organization imposed by the framework, and to some extent the programming language of the framework are the idiomatic architecture choices that are made for us the instant we choose one framework over another. The high level abstractions provided by the framework become your axioms. They are the constants in your development equation, the foundation of your code structure. If you buy into them, they will make you very productive. If you are in constant conflict with them, then you probably chose the wrong framework.
Intrinsic Architecture Choices
Where the idiomatic stuff deals with structure and organization, the intrinsic architecture choices get a bit more into philosophy and style. For example, just this morning I found a four year old article that could have been written last week or last century where the author describes his notion of a clean architecture. This article is purely intrinsic architecture, completely agnostic towards language choice, framework choice, or database choice. It doesn’t even make any assumptions about whether you are writing a web application or a desktop application. It is one man’s manifesto on how software should be built, and I have to say that I agree with it wholeheartedly and I’ve been living by most of the same principles for years myself.
If you are now or would like to become a Software Architect, it’s good idea to have a manifesto like this in place from the start. This is the intrinsic stuff, the stuff you believe in, the stuff that you will be looking for in code reviews, the long poles in your architectural tent. If you have Engineers working for you, they will need to understand that the code they will be implementing will be held up against these standards. If they fail to comply they will have to go back to the drawing board. Even the frameworks you choose will need to harmoniously co-exist with these principles.
Where Intrinsic and Idiomatic Architecture Choices Meet the Real World
So that’s a lot of background information and abstract talk. Let’s pull this back into the real world of how we build a real web site. In the real world, there are some times where intrinsic and idiomatic choices overlap a bit. Your choice of programming language, for example, is something that is at least partially dictated by the framework you choose, which is mostly a choice of idiom. However, that language may bring with it some contstructs and design philosophies that better serve your intrinsic choices of how the application should be built. Interestingly, the Play Framework from its very beginnings was supposed to be a “Ruby on Rails for Java/Scala”. Like no other framework I have seen, Rails seems to induce pure delight in developers who use it. This is so because you can get things up and running quickly, and because most of the drudgery of creating a web application has been replaced by a rational set of conventions that in most cases work the way you want them to with no need of additional configuration. Some developers left Java behind and went to Ruby and Rails to take part in the bliss, but some others said “why can’t we build a web framework in Java that brings about the same level of delight?”
It may be a leap to call Rails and Play “equivalent,” but if we can make that leap it means that language choice can come first and the framework will be dictated by the language selection. Before Play, if you wanted to have all of the developer productivity enhancements that come with Rails, Java was off the table and Ruby was your only choice. Either choose Rails or continue on with slow-to-develop, configuration-file-laiden, undelightful Java frameworks. This always rubbed me the wrong way, because I believe that Java (and now, Scala) provide me with a better toolkit than Ruby does for implementing intrinsic architectural choices that I have made and will be writing about in future posts.
This language debate is, of course, a religious one that has no correct answer. Maybe my writings will convince you that my choices are sound and you will join me. Or maybe you are resolute in your faith and in your own battle-hardened intrinsic architectural choices. But hopefully my experience and my attempts to write about it will be thought provoking and will give you some more ways to think about why you are building things the way you are. And hopefully you’ll agree with me. Because I’m right.
