Tacking Complexity Into The Heart Of Software

time to read 6 min | 1046 words

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 /