About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Framework Driven Development

I‘m planning to come up with a new methodology called “Framework Driven Development”.

10 zillion feet‘s view of the methodology: First build every god damn framework that could be needed by the application. Then think about building the actual application.

This methodology is dedicated to the big software enterprises that fantasize and build frameworks to support their applications.

Based on couple of projects that I have worked on, I see lot of companies investing a great amount of time, money, resources and efforts building wrapper frameworks, which are then slapped or enforced on the application development teams to use. For example, writing a framework on top of JDBC to execute simple SQL statements, building property management framework to handle properties file, building logging API for correctly using log4j and so on.

The justification for building these frameworks upfront [in ether] are:

1. Consistency: Usually big enterprises have at least 4 to 5 different teams working on a big project. They want all these teams to use the same architectural components in the same way. Hence consistency becomes very important.

2. Elimination of duplication: They do not want each team to develop their own architectural components. They want a repository of common code which could be used across the board.

3. Avoid reinvention: They don‘t want each team spending time figuring out how external components or libraries work. Reinvention is not just limiting to learning how to use a technology. It‘s an ongoing learning which needs to be centralized rather than distributed.

4. Ownership: They want a team to take ownership of the common architectural components and maintain/enhance/release in a consistent way such that all the teams are not impacted by external changes. For example, new version of a library is released, etc

5. Specialization: They want to form a focused group of specialists. By spreading them across teams will dilute their specialization and would lead to underutilization of the talent.

And the list goes on…

In theory these points seem very logical. But in reality I have not seen this model work effectively. Following are points that come to my mind:

1. Inconsistency: Though we have standards, each person customizes things further to suit their comfort and usage. And sometimes the base framework is much simpler than the new wrapper framework with all its added complexity, so people find they ways around the complexity.

2. Learning curve: Every new member on the team has an extra learning curve understanding the wrapper frameworks.

3. Too much fantasizing: Usually the team responsible for building these wrapper frameworks goes into a fantasizing spree and just builds things which are nice to have features but are never going to be used by any one.

4. Enforcing/retrofitting frameworks: Some of the best frameworks and patterns I have seen evolve out of the existing code rather than been coded upfront. The frameworks get optimized and blend very well when they happen as a part of coding. Trying to retrofit a framework makes the code look ugly and makes the program feel really uncomfortable

5. Integration nightmare: As the application team starts using the framework, they request for changed or bug fixes or whatever. Soon we have new version of the framework being available at irregular intervals. This integration always consume a lot of time and break a bunch of stuff in the applications. These integrations are also a great way to introduce bugs.

6. Hidden cost: Code is centralized and controlled is good, but it means that the turn around time for any change is very high. There is usually a bureaucratic process to request a change. This discourages teams to ask for changes and they invent ways of working around the problems. There is cost involved in inventing and maintaining code which has no business value.

7. Generalization v/s specialization: Having specialists on one team means the other teams have build the expertise from scratch and this might be painful and time consuming. It would be better to have specialists accessible on the team so that every one can quick get the knowledge transferred.

8. Handovers: Having separate teams have the implicit cost of handovers. This forces each framework to be well documented. Soon you find people spending more time documenting and beautifying things than doing actual work that adds business value to the customer.

9. Customer focus: The framework team needs to realize that the application teams are their customer and be focused to their needs. But it ends up the other way round, where the application teams have to take what ever the framework team dumps on them.

This list can also go on…

Though the intensions of these frameworks are good, I have never seen the process to implement them done the right way. One has to pay too huge a price for the value they add.

    Licensed under
Creative Commons License