<< Date Merging Challange Solved | Home | C++: Template Specialization >>

Tacking Complexity Into The Heart Of Software

No, the headline is not a typo.

It refers to a discussion that I had with a developer about the different advantages of developing application frameworks. The main points where:

 

  • Using text-book Microsoft's Mort approach – pass around data sets as the data layer all the way to the UI, business logic modify the data sets directly.
    • Advantages:
      • Easy to explain
      • Easy to get a developer up to speed on the project
      • Lots of resources and people running into problems that you would be able to Google.
      • Easy to see the flow of a single execution thread in the program.
      • Lot of tool support
    • Disadvantages:
      • Hard to work with when the application grows / change
      • Easy to get duplicate code, because business logic is scattered in data sets' events, some helper classes, wrapper object, etc
      • Very hard to see the flow of a program from a high level view
  • Using Inversion Of Control Container as well as object relational mapping:
    • Advantages:
      • Easy to work and develop with
      • Centralizing control of the application and reducing dependencies.
      • Very easy to extend the application
      • Very easy to see the high level flow of execution
      • Reduced complexity because can now use objects and OOD to solve issues
    • Disadvantages:
      • Requires training developers to use it
      • Not all developers can understand parts of the code base – the IoC's Container code, for instance
      • Hard to see a single flow of execution in the program

 

We both agreed that IoC + OR/M was a better approach from a technical / design point of view (feel free to agree, but I would like to hear why), the argument was whatever it was worth going this path when it would be harder to get developers to work with the system.

I am in the firm belief that an application framework should embed as much functionality as possible, and that building specific functionality to an application should be extremely simple for developers who know the system. My assumption is that if you are bringing new developers in and out of a project often enough that learning how the project works is a hurdle, you got more pressing problems to worry about.

The application we discussed was a live application, which means that it is constantly modified, updated and extended. Under those circumstances, I think that a big investment in an application framework will have a fairly significant ROI.

The other side is that while we are building the application framework, there is nothing much to show for it except some unit tests that doesn't really mean anything without a lot of explanations, and that is to other developers, not to business guys.

Going the Mort's way will allow other developers to start adding business value to the application immediately, but there would be a lot more work to do for most scenarios.

 

What do you think /

Print | posted on Friday, May 19, 2006 12:34 PM

Feedback

Gravatar

#  5/19/2006 3:03 PM Jordan T.

Funny! That looks the title of Eric Evans book - a big advocate of using domain models (see below).

&quot;Domain-Driven Design: Tackling Complexity in the Heart of Software&quot; - by Eric Evans
http://www.amazon.com/gp/product/0321125215/102-0298692-7046562?v=glance&amp;n=283155

Gravatar

#  5/19/2006 3:21 PM Ayende Rahien

Jordan, that is not an accident.
This is a hidden reference :-)

Gravatar

#  5/19/2006 3:59 PM Philip Nelson

I like the summary and it fits my own experience really well. Considering how many people now work as contractors, fitting the &quot;new developer coming on a project often&quot; scenario, it's not surprising that there is resistance to the richer frameworks. After all, these will be different on every project and the contractor has to deal with them all. Not surprisingly then, &quot;don't use contractors&quot;, especially remotely, is a common theme for domain driven and XP practitioners alike as the communication burden is too great. Are contractors represented correctly as Mort? Is it easy to find contractors that embrace your or my particular style of programming?

Gravatar

#  5/19/2006 4:32 PM Ayende Rahien

@Philip,
I am a consultant / contractor, and I rarely see the Mort application as is.
I am probably not called to the applications where this is satisfactory, though.
When I do get called is where they started out with it, and run into the limitations of this appraoch. I'm called to help them fix it.
Usually, by this time there is their own solution that is doing some of the work, they can't call anyone to help, nor benefit from the experiance of someone else.
That is not a good place to be.

Gravatar

#  5/19/2006 4:50 PM Murat

Since nowadays I am reading &quot;Domain-Driven Design: Tackling Complexity in the Heart of Software&quot; - by Eric Evans, I am a bit more alert to the topic here. The book talks about having a &quot;domain-layer&quot; in the application that reflects the entities and relationships among them in the business domain that software adresses. And aside from that layer you still have other layers depending on your application's needs. (UI, dataaccess, services etc) I think any nontrivial business application (which is doing more than saving data to db and reading back) should have some kind of &quot;domain-layer&quot; that reflects what the software is for. And that layer can be implemented best by OOP. IMHO implementing this layer with datasets is just carrying the object-database-impedance mismatch to the application. And datasets are not anywhere near in terms of extensibility of an effective OO design. Of course building that type of OO design is hard and more time-taking compared to dataset approach but I believe it has a high pay-off.

That is my .02c on the topic.

Gravatar

#  5/19/2006 7:33 PM David Hayden

Overall, I agree.

However, even Eric Evans mentions the value of the Smart UI &quot;Anti-Pattern&quot;. Over-architecting a simple application is just as terrible as over-simplifying a complex application.

I am a big proponent of DDD when it makes sense for my &quot;complex&quot; application, because it gives me the sustainability I need. However, I also embrace simple ActiveRecord type patterns, for example, for applications with few business rules and very little need for loose-coupling and strict separation of concerns.

I understand the implied context as to what you are saying, so I agree. However, an inexperienced developer may take your post to mean that all applications require a sophisticated domain layer, O/R Mapping, MVC, etc. The truth is that many &quot;simple&quot; applications would be better off not using such solutions as they would only increase time-to-delivery, add to maintenance and development costs, require more developer expertise and training, and in-the-end offer absolutely no value.

The key to all of this is using the right tools, technologies, and solutions for the project within the budget, timeframe, and resource restrictions placed on the project. If you've got the time, resources, and an application that would benefit from a DDD-style architecture, go with DDD :)

Gravatar

#  5/19/2006 8:57 PM Ayende Rahien

@David,
I can agree with what you say, a simple application can be done using RAD very quickly, and that is a good ROI.
A RAD app is usually (hopefully!) not going to have a long shelf live, nor is it going to be very complex.

If that is the scenario you have, and you know the tools, go crazy with it.
I've a lot of experiance with those frameworks, so I can get a very quick result out even for simple applications. I found that it is fairly easy to work in multiply levels of the tools, since that is where you can get the most value.

@Murat, I fully agree with you there.
Just the stuff you need to do to support discriminator columsn is crazy.

Gravatar

#  5/19/2006 9:54 PM Philip Nelson

At the risk of over playing the building trade metaphor, there is a reason that the same people who build residential houses don't often build commercial buildings or skyscrapers and visa versa. The difference is that for the most part, buyers understand the difference between a house and a building, so the correct builder gets the call in most cases. For us developers, I think a lot of us are guilty of thinking to use the hammer in our hand rather than selecting the correct tool for the job!

Comments have been closed on this topic.