Blog Battle – SEP is currently having a blog battle between some of the employees. This weeks challenge is the title – I Don’t Have Time.

I have, on occasion, been asked where I find the time for playing with all of these cool languages and frameworks. Or presenting. Or teaching an internal class.

Funny how no one ever says, “Where do you find the time to watch America’s Got Talent?”

When someone says the don’t have the time they are actually saying, “That’s not important to me.”

About a year ago, I started studying for a .NET certification upgrade. Since SEP is a Microsoft Gold Partner, they made it worth my while to maintain my certification. It wasn’t easy. I spent at least a couple hours on most nights studying for about three months. The opportunity cost was I could have spent that time with my wife. I would have spent that time playing with frameworks, software, etc, but I would have done it while watching TV with her as she wrote lesson plans, graded papers, or made crafts. Or helping run the house. Fortunately, she had buy-in on this endeavor since that much time impacted her life as well.

I don’t go fishing. I don’t watch the local sports team with friends. Software is my hobby. I used to play role-playing games with my coworkers. I used to draw a webcomic. While I still enjoy those things and occasionally still draw and game, I have other things I would rather be doing most of the time.

When I explained this, I was told when I have kids I’ll understand that doesn’t fly.

Surprise! My wife and I now have an infant daughter. Here’s the deal as I see it now.

It is still a matter of setting your priorities. Figure out what those are and align your life to them.

Shortly after we returned to work we realized that just about all we were doing was either cleaning the house or taking care of our daughter. Or in her case prepping her class of first graders. So we’ve made a simple deal. We need to find time for one another to do the things that make us who we are. She has blocked out time to bake and make cards. I have found time to attend a user group, read, draw, and even blog on occasion. We shop together and find time to eat out. These take time. I could take Sophie grocery shopping, leaving my wife time to lounge on the patio with coffee and a book, But it’s time we are willing to spend because it is time spent together. And she hates coffee.

The other thing about our doing those things they are either scheduled or can be done in snatches.

Some things are still not happening. I don’t get much of a chance to play music since I’d rather spend my time elsewhere. I don’t attend Code and Coffee because I’m driving Sophie at that time in the morning. But I’m not whining about those losses. I have chosen. I have edited down my life to handle a bigger priority. I love the time I spend with my little girl, and I’d rather spend time with her than many other things I also enjoy.

Let me walk through some time sucks and cases why you might choose to spend that time.

I work 60 hours a week or have a long commute. Some employers are the only way to get health benefits for children and spouses with preexisting conditions. To make enough to raise a child with a stay at home parent, you may have to trade a ‘fun job’ for a better paying job at the expense that you yourself spend with your children. Self employment sometimes trades the flexibility and autonomy for time.

My kids have so many activities. You enjoy spending time helping your kids find friends and activities they are passionate about. You may even enjoy participating along side.

I have to fix up my fixer-upper house. You traded home cost for your time. You enjoy rebuilding the house and making it your own.

I have meetings with some organization. You find participation with this group fulfilling. Or you see networking opportunities that are important.

There is no secret to finding time. You can’t fit 25 hours in to a day. You sleep less or do less. I would avoid sleeping less. I have an infant daughter and I know where that leads.

So, let me challenge you. Next time you find yourself saying, “I don’t have time.” Ask yourself if it’s because life happens to you, leaving you with no choices. Or admit that you have other priorities and it’s just not as important. Then find peace with that.

Just a quick refresher of my last post; I hate layers and prefer the ports & adapters architecture I drew in the following picture.

The next logical thought is probably, “Okay Mr. funny man. What the heck is going on inside that big green blob?” The same thing you should put inside the green part of the layers picture. Oh, the n-tier app guys don’t talk about that very much, do they?

The easy first draft of the green layer is to simply takes the objects you’ve mapped on to your data store, right? This works for many situations where the UI is essentially directly manipulating the underlying data. This is what Trygve Reenskaug had in mind when he codified the MVC pattern. It is also close to the Naked Object pattern.

But it falls down with complex inter-object interactions. The problem is just your normal run of the mill OOP as widely practiced, the translation of nouns to classes. You end up with jealous classes, classes with multiple responsibilities, and a bunch of untested business logic repeated in your controllers/activities. That means that your probably have an implicit relationship hiding in your code.

When these relations and interactions are important enough, they should be made explicit by creating An object to manage interactions. This is better OOP, but I’d you need some ‘further reading,’ try taking a look at Domain Driven Design or Lean Architecture’s DCI. They both get to similar places, but with slightly different paths. DDD shuns the anemic domain model favoring rich behavior; while DCI favors simple data objects that compose with traits to which own behavior to be used in context objects managing their interaction.

I’m currently leaning towards a DCI inspired approach. First, DCI is a when necissary approach. If simple MVC/MVVM/etc work, then lean towards that. When, however, a use case gets complicated enough, you reach for the DCI to simplify the controller code. I can’t claim to use pure DCI since not all environments in which I develop have ‘traits’ or some similar code composition mechanism, but what is interesting is starting to think about your controllers acting on contexts and not directly on the data. And a context is nothing more than your use-cases turned in to code. the other parts of DCI are the data and interactions. Data is just dumb data, what DDD calls an anemic domain object. An interaction is a trait applied to a data object enabling it to play a role. Interactions are not necessarily meant to be widely reused as each collection of context and interactions can be thought of as a bounded context. If you don’t have traits then consider this non-exhaustive list of the following fine options; a context specific subclass, a decorator, a wrapper object, or interface aggregation.

What’s good about this approach? For starters, it is far more testable since you are controlling the BL interactions with easier to mock interfaces. In addition, the explicit decoupling of regions of a complex page mean you will be more aware of interactions between those controls, and we’ve all had pages that start to have emergent behaviors and eventually end up sentient. You know, the one that keeps getting the change requests and bug reports.

Some further reading:

• Lean Architecture – The book that defines DCI
• Guiding Object Oriented Software Guided by Tests Test Driven Software from Use Cases
• Objects on Rails
  Fitting better OOP in to a controller environment
• DCI and Rails an overview on DCI and Rails
• The Right way to Code DCI in Ruby a second post on DCI and Rails
• Destroy All Software – Application Overview a walk-through of an object oriented design consumed by a Rails app
• Clean Architecture Bob Martin’s thoughts on ‘proper’ application architecture
• Uncle Bob’s Ruby Midwest 2011 keynote, Architecture the Lost YearsSame content in video form