Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Specialization vs Generalization

Derek Comartin Leave a comment

Depending on your location and the amount of opportunity may ultimately decide which side of the fence your on.

For me, understanding why a tool/framework exists and the problem is solves is much more important than understanding how to use a specific tool/framework.

Anytime the hiring discussion comes up, I am always reminded of this.  While do people classify themselves this way in a resume?  Django Developer?  I guess if you only want to develop in Python using an MVC framework, then sure.  But doesn’t this tend to lead to “When all you have is a hammer, everything looks like a nail”.

The understanding of a pattern or practice is transferable between programming languages and frameworks.  NHibernate or Entity Framework?  StructureMap or Unity? Who cares!  You probably won’t touch the delta anyway.

Progress with imperfect information

Derek Comartin Leave a comment

While I was attending Agile & Beyond last year, David J. Anderson did a great keynote on “stop doing agile, start thinking agility”.  In that keynote he said something that has stuck with me: Making progress through imperfect information.

There seems to be a stigma with refactoring.  It might not be refactoring, but getting it right the first time mentality.  We want to create the right solution and fear making the wrong decision because we don’t have all the information we think we need.

Make progress with imperfect information and refactor later when more is known or wait for better information?  I believe the best option is to deliver working software earlier.  This now leads into Continuous Delivery… maybe a post in the future.

Remember, you can only make a decision based off of the information you have at that moment.  Is it possible that you will see a flaw in your decision and have to refactor? Of course, but embrace change!

 

CQRS: Read Model

Derek Comartin Leave a comment

Keep it simple.  There isn’t much of a need to go out of your way adding extra layers of abstraction.  Any data access framework or ORM you might be using will already be creating a good enough level of abstraction.  With linq (IQueryable) being implemented in NHibernate, Entity Framework, or Linq to SQL, ORM du jour, you already have your a level of abstraction to your data source.

Need to query your read model from the client? Single page application maybe?  Ok… you need one more layer.  OData to the rescue.  WCF Data Services provides an incredibly easy implementation with Entity Framework.  ASP.NET Web API does have an OData implementation but has limitations.

Keep it simple:

  • Data Source
  • Data Access Layer (ORM)
  • OData Layer – only if needed if client is making the query
  • Client