A few months ago, myself and a colleague gave a presentation addressing the benefits for a software development company to use a shared development framework.
Based on our experience on projects and specifically the one we were currently working on, we came up with the following challenges when not using such a shared framework.
- A lot if not most development time is spent on plumbing code instead of business logic.
- No reuse of code across different projects.
- Most projects are difficult to maintain and upgrade due to custom development.
- There is multiple architectures and development patterns across projects, so no consistency.
We proposed a framework that could be shared across all departments and/or custom development projects. Of course, I insisted to base the design on CSLA. I’m not going to go into the reason for my decision, other than saying read my posts regarding CSLA and the frameworks’ definition. We’ve also suggested to use T4 as the code generation technology for the proposed framework.
Some of the benefits we’ve identified are:
- Flexibility
- Choice of data access technology i.e. LINQ, ADO.Net and even Entity Framework
- Choice of any frontend technology i.e. Silverlight, WPF, Windows Forms, ASP.Net
- Plug in any service layer/use any pattern with minimal changes
- Standardized Framework – Any developer can support it. Reduced knowledge transfer time.
- Decrease Development Time higher GP’s.
- One click generation of stored procedures and business objects using T4
- Can be used with DSL(Domain Specific Language) tools for VS.
- Solid Object Orientated Concepts.
We were pretty excited about the idea, for our proof-of-concept we showed how you can create your business objects using T4 and a Linq2SQL dbml file for the metadata.
To put it lightly we received a muted response. I think mostly we might have shocked and awed them with our demo app. The thing is (in my experience so far), it seems only a few IT professionals working in the .Net space have ever used business objects and even less of them have ever data bound it to a form. Nonetheless, that’s for another post.
Back to our shared development framework…a month or so after our presentation, a young developer gave a demo of an innovation that would generate a certain amount of helper functions to streamline unit testing. Only problem was, this innovation only applied to the architecture on the project he’s currently working on…all other projects currently underway in the organisation would not be able to benefit from this innovation.
To conclude; despite receiving a muted response, we are seeing a shift towards a more object/code-generation approach in the organisation, people do see the benefit of a layered architecture as they work on more complex projects. So, there is hope